How should command substitution (`...`) work?

[kendall at talcott.uucp]

>      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