Re: redirection and built-ins

[haahr@mv.us.adobe.com (Paul Haahr)]

Alan writes:
> | ``echo ... | read foo'' is not the appropriate construct in rc or es.

> Yeah, because it doesn't work; there is nothing intrinsicly
> `inappropriate' about it.

i disagree.  it's inappropriate because rc already has a perfectly good
mechanism for setting variables to the output of commands:  backquotes.
why is that not enough?  what functionality does that lack?

i don't think that the goal in rc was to provide a million different
syntaxes for the same operation.

> and I was actually thinking of a functionally-implemented read.

what does this mean?  (``functionally-implemented''?  that it works?
that it doesn't have side effects?)

> When
> I mentioned rc forking to provide redirection for built-ins, I was
> also thinking about functions, but it was sloppy writing on my part.

as far as i can tell, there are two issues here:

	(1) rc forks for all redirection operations, even ones which
	    are applied to builtins and shell functions.

	(2) rc and es fork a child process for each component of a
	    pipeline, even if some of the components are builtins
	    or functions.

(1) is handled differently in es, and seems to work ok.  in my
mind, it's a performance hack, and not a very good one, because
from the bit of profiling that i've done it doesn't make that much
of a difference.  the mechanism we came up with for doing this in
es could be applied to rc just fine, but it seems like a lot of
work for very little payoff.

(2), i think, is the right thing, because it's the only symmetric
answer.  in the pipeline
	a | b | c
if all a, b, and c are shell functions, which one should run in
the context of the shell?  what should happen if the command is
	exit 1 | exit 2 | exit 3
?  i prefer the current rc/es answer which is:  the shell does
not exit, and the return status is (1 2 3).  i believe that in
Tom Duff's verion, the top-level shell exits with either 1 or 3,
and Alan seems to argue that 3 is the right answer.

paul