

GNU grep 2.12 changes behavior of recursion options, breaks existing scripts - cschramm
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678652

======
js2
Here's the change and it's justification:

[http://git.savannah.gnu.org/cgit/grep.git/commit/?id=c6e3ea6...](http://git.savannah.gnu.org/cgit/grep.git/commit/?id=c6e3ea61d9f08aa0128a0eb13d31a2fbad376f99)

 _Change -r to follow only command-line symlinks, and by default to read only
devices named on the command line. This is a simple way to get a more-useful
behavior when searching random directories; the idea is to use 'find' if you
want something fancy. -R acts as before and gets a new alias --dereference-
recursive._

Personally I think breaking compatibility for this change was a poor decision.

~~~
akkartik
That link doesn't work. I thought at first that it was incorrectly copied, but
you can see it here:

[http://git.savannah.gnu.org/cgit/grep.git/log/?qt=grep&q...](http://git.savannah.gnu.org/cgit/grep.git/log/?qt=grep&q=Change+-r)

And clicking on it says 'No repositories found'. Anybody else have this
problem?

~~~
js2
Alternate link:

[http://repo.or.cz/w/grep.git/commit/c6e3ea61d9f08aa0128a0eb1...](http://repo.or.cz/w/grep.git/commit/c6e3ea61d9f08aa0128a0eb13d31a2fbad376f99)

(Yea for the "D" in DVCS.)

Also, the corresponding bug which has additional discussion:

<http://savannah.gnu.org/bugs/?17623>

~~~
Ralith
Just FYI, "Yea" and "Yay" are not synonymous.

~~~
js2
Doh. I see I mistyped "its" up above as well. (Or maybe iOS did that for me.)

------
larrik
The biggest problem I see is: who the heck would expect a .12 release to break
compatibility in an ancient and solid piece of software?

~~~
sneak
Why is grep being modified at all? It is clearly not broken.

~~~
Aglet
To quote a recent Coding Horror post, its bugs are now Common Law Features,
and must be supported.

------
buster
Who thought it might be a good idea to break -r (most likely the most often
used option) and use the old behaviour for -R?

Wouldn't it be better to atleast let -r behave like ever and change -R?

Anyone ever used -R here? :)

~~~
_delirium
-R is the POSIX-standard flag for recursive grep, so that would be worse to change imo. It's also the flag used for recursive grep by the BSDs (some of which do support '-r', but only as a deprecated historical option... OpenBSD calls it "strongly discouraged").

~~~
eschulte
Thanks for these important missing bits of information, in light of these I
think the change sounds much more reasonable.

/me updates rgrep alias to use -R

------
cschramm
Another thought: Since rgrep is an alias for grep -r and grep -r has changed,
the complete rgrep tool has changed and this can _not_ be fixed by using the
"right" switch. Hence rgrep is useless for scripting now.

------
pooriaazimi
This is a serious question: Why would you want to use plain old "grep" instead
of "ack"[1]? Of course, other than the fact that it's on all machines. Why
would you use it instrad of "ack" on your own machines? That's an honest
question, I'm not starting a flamewar... The highlighting and filename/line#
by default is the killer feature for me.

Edit: Come on. Downvotes for this? Honestly... It's HN, not StackOverflow. You
don't mark questions as "off-topic" unless they're trolling...

[1]: <http://betterthangrep.com>

~~~
greyboy
That's a fine recommendation for machines that you solely work on, or have
complete control over. However, it's good to be able to work with the standard
toolset if you frequently work on a variety of remote machines (where it's
quite common that you cannot install such things, due to permissions or
policies, and want to get started working before attempting to
download/install a bunch of custom binaries).

Edit: MattJ100 made a more clear point while I was responding.

~~~
pooriaazimi
Thanks for the response. However, a nice thing about ack is that it's not a
binary (necessarily) - it's a perl script and can be used without sysadmin
permissions: <http://betterthangrep.com/install/>

The other points are quite understandable and correct though. It's always best
to at least be familiar with standard tools, even if you want to use an
slightly different version for yourself.

~~~
greyboy
I think we're probably mostly in agreement, even if I wasn't clear about it.
In my line of work, there have been times where I was not permitted to use
external scripts or binaries (highly sensitive environments). However, that
one small example doesn't mean ack should be disregarded!

------
rwos
It's funny how one of the relatively few design errors in Unix shells now
indirectly comes back to haunt us. Recursing is built into pretty much every
command that can handle multiple files - which very strongly suggests it
should have been made a feature of glob (or the shell).

I think it's a bit sad that those "big-picture" features in unix are treated
as if the were written in stone.

~~~
nvarsj
This is one of the great reasons to use zshell. :-)

    
    
      grep -in **/*txt "sometext"

------
JoachimSchipper
Remember: GNU is _not_ UNIX.

------
m0skit0
Backwards compatibility is an evil illness that sometimes must be broken. It's
for the good of evolution. I praise engineers that make such decisions, even
if they are unpopular.

~~~
TillE
When there's a clear benefit, that's great. Feel free to scrap backwards
compatibility when there's significant progress to be made in doing so.

This feels a lot more like a "color of the bike shed" choice. There are use
cases where the new behavior makes sense, sure, but there are also plenty of
cases where the old way is better. This isn't an upgrade, it's a lateral move.

~~~
tinco
So we have to continue with an ugly bikeshed for the rest of eternity? I think
it's very important that whenever it is decided that objectively one way of
doing it is better than another way that eventually that way finds itself to
be the way it is.

You basically imply that this change is not big enough to warrant a break with
backwards compatibility, but small discontinuities and hacks add up. If thinks
like this aren't fixed every once in a while the system will be ridden with
inconsistencies.

Besides, even though it hurts when you've inherited some crazy unreadable code
that utilizes some obsoleted functionality I think it is always positive for
the code quality when the chaos monkey comes around and breaks something.

edit: the downvote button is to indicate I am detrimental to the discussion,
the reply button is for when you disagree with me :)

~~~
uxp
If this actually fixes a legitimate problem (which is what?), I don't think
anyone thinks that it shouldn't be fixed, just not at a x.12 release.

This changes breaks rgrep, thus it should be held until a full version (3.0).

edit: my FreeBSD's `grep` manpage:

    
    
        -R, -r, --recursive
               Read all files under each directory, recursively; this is equiv-
               alent to the -d recurse option.

~~~
koenigdavidmj
FreeBSD grep is just GNU grep, it appears, up to but not including 9.0. Note
the long --recursive option in the manual page snippet that you posted; no
properly God-fearing BSD program would support long options.

~~~
jasomill
The new non-GNU grep in FreeBSD 9 was designed to be compatible with GNU grep
(pedantically, with GNU grep configured with --disable-perl-regexp as it has
been in previous FreeBSD releases) because lots of ports depend on GNU grep
behavior. The fear of God is not a sufficient reason to break ports.

------
snorkel
I also decided that sed no longer supports regexes because I said so. And ls
-l will now shows a list of print jobs instead of files because maybe that's
what you meant. ... oh and ping no longer supports IPv4 because I want
everyone to adopt IPv6 immediately because I said so.

