Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site gypsy.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!siemens!gypsy!rtd
From: rtd@gypsy.UUCP
Newsgroups: net.bugs.4bsd
Subject: Re: slight problem with grep.
Message-ID: <29700003@gypsy.UUCP>
Date: Wed, 5-Feb-86 13:46:00 EST
Article-I.D.: gypsy.29700003
Posted: Wed Feb  5 13:46:00 1986
Date-Received: Fri, 7-Feb-86 20:45:20 EST
References: <9299@ritcv.UUCP>
Lines: 37
Nf-ID: #R:ritcv:-929900:gypsy:29700003:000:1442
Nf-From: gypsy!rtd    Feb  5 13:46:00 1986


Actually, the program at "fault" is the shell.  The issue is, given any
command line of the form

    cmd * > file

which comes first: filename substitution or output redirection?

Assume that "file" does not exist.  If filename substitution is
done first then "*" expands to the names of all existing files, which
doesn't include "file", and everything works as you'ld probably expect.
If output redirection is done first, "file" is created and "*" expands
to a list of files which now contains "file" and you get the behavior
described in the original note.

There seems to be no consistency among shells as far as the order of
these operations is concerned.  On 4.2 BSD, csh(1) does output redirection
first, followed by filename substitution, while sh(1) does things in the
reverse order.  To determine easily how your shell works, execute the
following command in a directory that doesn't contain a file called "xxx":

    echo * > xxx

After executing this command, if file "xxx" contains the string "xxx" then
output redirection occurs first.  If not, filename substitution occurs
first.

By the way, I too executed the offending "grep" command on an early
(about 8 yrs. ago) version of AT&T Unix on a PDP 11/70.  The result was
extensive file system corruption followed by a system crash.  And
you thought Unix has mediocre protection schemes now? :-)


Bob Dillberger
Siemens Corp. Research & Support
Princeton, NJ
siemens!gypsy!rtd