find and coments [was Re: [plug] FW: New network card - update]

[Nick Bannon]

On Sat, Oct 31, 1998 at 06:05:55PM +0800, Shackleton, Kevin wrote:
> Got it:
> 1) to search lots of files:
> 	find . | xargs grep "0x300"

The traditional way is ;

find . -type f -exec grep "0x300" {} \;

This starts a separate copy of grep, with {} replaced by each filename,
for every file starting from the current directory. This is quite
slow...

(it also won't print out the filenames: tack -print onto the end, or
use grep -l to do that, depending on what you want)


find . -type f -print | xargs grep "0x300"

is the sped up version. This prints off every filename, and feeds it
into xargs. xargs takes a few filenames at a time and sticks them onto
the grep command line, cutting down on the number of times grep is run
tremendously. There's a catch - what if the filenames have spaces in
them? Then grep would try to open the first part of the filename (which
wouldn't exist) then the second part of the filename (which wouldn't
exist either).


Happily, we all use GNU systems here - we might use Linux kernels, but a
large chunk of our system programs, like find, xargs and grep, come out
of the GNU project to rewrite all the standard utilities that a
replacement UNIX-like operating system would require, usually improving
them as they go.

find . -type f -print0 | xargs -0 grep "0x300"

This does the same thing, but puts a null character (which for practical
reasons won't be found in a filename) after each file. xargs -0 looks
for nulls as the separating character and feeds the complete filenames
off to grep.


grep "0x300" `find . -type f`

as suggested has the same "spaces in filenames" problem. If you've got a
lot of files to search through then it would also make for a very long
command line - modern shells should cope with that, but many older versions
had limits on how long a command line could be.


...and finally there's just using the shell in the first place. The zsh
solution is ;
grep "0x300" **/*(.)

and it would handle spaces perfectly well.

[...]
> p.s. anyone want to comment on the history and current applicability of
> semicolons and hashes as comment markers?  Does each come from differnet
> schools?

These (and many more) get used. It doesn't have to be a single character,
either - C (/* ... */), C++ (// ...) and BASIC (REM ...) comments get used
all the time. You have to remember what context you're in, unfortunately,
but hashes are a pretty common default for UNIX shell-type things.

Remember to be careful with BIND - a recurring gotcha when editing DNS
configuration files is that it only understands semicolons. Instead of
logging some useful and explanatory error message it will simply no
longer successfully send out updates.

Nick.

-- 
  Nick Bannon  | "I made this letter longer than usual because
nick at it.net.au | I lack the time to make it shorter." - Pascal