grep -l problem on 4.3bsd

[trb at ima.UUCP]

I had a spool directory full of bogus requests, do to a loop condition
- 600 files, each 50K bytes long.  Each one was easily distinguished by
its header.  Anyway, I typed

	grep -l name *

to get a list of candidates for deletion.  It was taking an awfully
long time.  I mentioned to a fellow hacker that it seemed stupid that
grep -l with a hit at the top of the file shouldn't be instantaneous.
He told me that it was, and sure enough, on his tty, it was.  After
looking at all kinds of silly little things like environment sizes,
shell attributes, etc., we realized that he was running /bin/grep and I
was running /usr/ucb/grep.  Sure enough, /usr/ucb/grep grinds through
the entire file, whereas /bin/grep pops out after the first match (by
seeking to eof and having the read do the normal eof processing).

My slow grep was grinding for about 15 minutes when I ran the fast grep
which finished well before the slow one would have.  Grepping through
headers is a pretty common operation, so I thought you all would want
to know about this problem with 4.3bsd /usr/ucb/grep.  Note that
/bin/grep and the grep in the BRL Sys V emulation both do the right
thing.

	Andrew Tannenbaum   Interactive   Boston, MA   +1 617 247 1155