lat@stcvax.UUCP (Larry Tepper) (12/01/84)
Today I was looking for some old news articles. I cd'ed to
the appropriate news directory and typed:
p `egrep -l pattern *`
If you aren't familiar with it, "p" is a program from Kernighan
& Pike that displays a screen of text and waits for the user to type
RETURN before displaying the next screen.
As it turned out, the pattern wasn't found in any of the
articles. Egrep returned a non-zero status without printing any
file names. The shell then ran "p" without any arguments. "p" of
course just sat there for a long time waiting for me to type something.
Since there were over 100 articles, I was unsure how long to wait
before killing it. I have since checked, and the grep took 50 seconds
under a light load (avg < 3) on our VAX 750. We run 4.1BSD: both csh
and sh exhibit the same behavior with command substitution.
It seems more natural to me that the shell should (silently) not
run a pipeline if any command substitutions in it fail. Csh behaves in
a similar manner when a pattern substitution fails, e.g.
% ls [A-D]*
No match.
although in this case the error condition (pattern match failed) is
internal to csh. I don't particularly appreciate the "No match",
though. (I especially don't appreciate "Broken pipe", but that's
another article).
One way, at least, around the problem would be to type:
echo "" | p `egrep -l pattern *`
As an experienced UNIX user, I can live with this. However,
I don't believe a novice user would expect the current action. I
don't think the suggested change would be obnoxious to even experiened
users. The user would be getting some useful feedback about what
has transpired.
The problem with changing the shell to work as I have suggested
(I won't say "fixing the shell", because the current behavior is probably
a feature) is that there are probably shell scripts written DEPENDING
on this.
What do you folks think?
--
One of the survivors...
{ihnp4 hao philabs sdcrdcf ucbvax!nbires}!stcvax!lat Larry Tepper
Storage Technology, MD-3T, Louisville, CO 80028 303-673-5435gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/01/84)
> p `egrep -l pattern *` > > It seems more natural to me that the shell should (silently) not > run a pipeline if any command substitutions in it fail. The Bourne shell "never" fails on a file pattern; if there is no match it just uses the pattern itself. There was at one time a shell variable called FILEMATCH that one could set to obtain a different behavior, but there was not much enthusiasm for this so it went away.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/01/84)
> p `egrep -l pattern *` > It seems more natural to me that the shell should (silently) not > run a pipeline if any command substitutions in it fail. In case the filename matching is a side issue and you are mostly concerned about the shell continuing when the `` command returns a non-zero exit status, I definitely HAVE seen instances where the current behavior is desired. Non-zero exit status is not always a catastrophic failure, as in the case of grep. BRL UNIXes have a ^T "mini-systat" feature that lets one easily determine whether he needs to type something (process shown as blocked awaiting terminal input). This is an ugly but useful hack that makes accidents like the above much easier to cope with.
kendall@talcott.uucp (12/09/84)
> Today I was looking for some old news articles. I cd'ed to > the appropriate news directory and typed: > > p `egrep -l pattern *` > > If you aren't familiar with it, "p" is a program from Kernighan > & Pike that displays a screen of text and waits for the user to type > RETURN before displaying the next screen. > > As it turned out, the pattern wasn't found in any of the > articles. Egrep returned a non-zero status without printing any > file names. The shell then ran "p" without any arguments. "p" of > course just sat there for a long time waiting for me to type something. > . . . . > > It seems more natural to me that the shell should (silently) not > run a pipeline if any command substitutions in it fail. Speaking in a sort of Pikeian mode, I think the root of the problem is the tradition of UNIX-style programs to take input from files if given one or more filenames as args, but to take input from stdin if given no arg. If n args means take input from n files, n should be allowed to be 0 (which would mean no input at all), and the "-" argument should mean stdin. Perhaps then it would be reasonable for shell patterns to yield nothing if there was no match, as I theorize that God intended it. It's a little late for UNIX on this point, but for future command interpreters and argument conventions . . . . Sam Kendall {allegra,ihnp4,ima,amd}!wjh12!kendall Delft Consulting Corp. decvax!genrad!wjh12!kendall