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.
If it's not a load issue and neither some intended limitation to prevent load issues, somebody pulled it on purpose. ...which I actually included in not being able to handle HN. ;)
the idea is to use 'find' if you want something fancy
I don't get it, can someone explain? It also appears in the ML thread linked elsewhere, and I don't understand it there either. (I understand the reasons for the change in behaviour, just not this specific line.)
find is essentially the command line tool for traversing the file system hierarchy recursively. It's got a million options, e.g. whether to follow symlinks, depth, file/directory/device/.., user, group, change time and many more. When you use grep -r, it only does the most common thing which is to just go over all the files. If you want something more "fancy", you can use find, e.g.:
Comments
Here's the change and it's justification:
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=c6e3ea6...
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.
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...
And clicking on it says 'No repositories found'. Anybody else have this problem?
Alternate link:
http://repo.or.cz/w/grep.git/commit/c6e3ea61d9f08aa0128a0eb1...
(Yea for the "D" in DVCS.)
Also, the corresponding bug which has additional discussion:
http://savannah.gnu.org/bugs/?17623
Just FYI, "Yea" and "Yay" are not synonymous.
Doh. I see I mistyped "its" up above as well. (Or maybe iOS did that for me.)
Yes, seems like Savannah can't completely handle HN ;)
The error message doesn't suggest this is a load issue. Also, wouldn't the entire app go down rather than a single link?
If it's not a load issue and neither some intended limitation to prevent load issues, somebody pulled it on purpose. ...which I actually included in not being able to handle HN. ;)
The commit details are back now. :)
the idea is to use 'find' if you want something fancy
I don't get it, can someone explain? It also appears in the ML thread linked elsewhere, and I don't understand it there either. (I understand the reasons for the change in behaviour, just not this specific line.)
find is essentially the command line tool for traversing the file system hierarchy recursively. It's got a million options, e.g. whether to follow symlinks, depth, file/directory/device/.., user, group, change time and many more. When you use grep -r, it only does the most common thing which is to just go over all the files. If you want something more "fancy", you can use find, e.g.:
Relevant thread on the ML:
https://lists.gnu.org/archive/html/bug-grep/2012-03/msg00028...