I've found "find / -xdev -type f -print0 | xargs grep string /dev/null" to be completely reliable and reasonably portable. Not to mention a lot faster. Faster yet if you use any of the #NN arguments to xargs to batch the grep invocations. I started doing that because every time I ran grep -r, it would just hang somewhere in /etc. -Adam -Adam
On May 4, 2015 10:51:08 PM CDT, Trevor Cordes trevor@tecnopolis.ca wrote:
On 2015-05-04 Gilbert E. Detillieux wrote:
A read on a file in /dev will almost always trigger an action (usually causing data to be read from a device, of course), but I
Hmm, that's a good point. I suppose a read on a device could "steal" the input another program was expecting.
It's strange though, because now that I think about it, when I run grep -r /, I'm pretty sure it's not reading all the disk block files, etc, as it runs way too fast for that...
Ah, I forgot I had this set as an alias to grep on every system I use: /bin/grep -s --devices=skip
I just checked and this new Rackspace box indeed had my alias set! So the plot thickens! So it's two possibly bugs: why was grep even reading that watchdog device in the first place; and why did reading it trigger a reboot?
can end up in symlink-induced loops. I'd also avoid going
I've never actually ended up in a symlink loop, but I can see how it would be easy to run into. I guess I don't use many dir symlinks on my systems.
Or... I just RTFM and it looks like gnu grep solved the symlink problem already:
-r, --recursive Read all files under each directory, recursively,following symbolic links only if they are on the command line. Note that if no file operand is given, grep searches the working directory. This is equivalent to the -d recurse option.
-R, --dereference-recursive Read all files under each directory, recursively. Follow all symbolic links, unlike -r.So that explains why I've never hit a symlink loop: I've never used -R (capital).
Ah, even better: -D ACTION, --devices=ACTION If an input file is a device, FIFO or socket, use ACTION to process it. By default, ACTION is read, which means that devices are read just as if they were ordinary files. If ACTION is skip, devices are silently skipped.
So that means my -D skips every "weird" file. That means that I've definitely, for sure, hit some bugs here. There's absolutely nothing now that should stop anyone from safely doing a:
grep -r -D skip /
on any system with modern gnu grep.
The main reason I want to be able to do grep -r / sometimes is that I need to find a string (like an IP address) that may be scattered literally anywhere on the fs. In the past when I say to myself "oh, it must only be in /etc or /var or /home", there ends up being some little file in /usr (not even /usr/local) or wherever that was changed ages ago for whatever reason to work around whatever problem, and it gets missed unless I just "grep the whole darn thing". And to ls / and go through the 10-15 items in my brain deciding if they are greppable or "system/non-greppable" takes time and is error/omission-prone, and to list each one on the command line is a pain. Now this would be easier with a shell like zsh that has "negative globs" where I could specify "* except /dev /sys" (ie just make an "exclude" list, not an include list), but my beloved tcsh doesn't have that and I'm not ready to switch to zsh yet. And like I said before, each UNIX has its own different set of "don't grep this" dirs, and they change over time (even in Linux), so making a "one-alias fits all" is a non-solution. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable