Re: FAQ E4

[Maximillian Murphy]

Am 26 Apr 2008 um 21:49 schrieb Chet Ramey:

> Maximillian Murphy wrote:
> > E4) If I pipe the output of a command into `read variable', why  
> > doesn't
> >     the output show up in $variable when the read command finishes?
> > Would it cause a great deal of upset if the last section of a  
> > pipeline ran in the current process?
>
> It could work when job control is not active -- nobody has done the
> work -- but is fundamentally incompatible with job control and
> process groups.
>
> Chet

Is the problem one of catching signals?  So if (and it's a big if) I  
can find a way of handling control-z, control-c etc and getting the  
expected reaction then I'd get the go-ahead?

A solution would be to consider forking on catching a signal so that  
if a pipeline is say sent to the background one half can background  
and the other return to the user.

My current feeling - having hardly looked at the code - is that this  
should be feasible.  Are there any other problems to consider before  
dedicating serious time to this?


An alternative would be to go straight for a general primitive and  
find a way of allowing each section of a pipeline to set values in  
the original shell.  Each section could return a string that would be  
evaluated in the main shell:

echo humpty dumpty | wc | { read lines words chars ; tellparent  
"lines=$lines ; words=$words ; chars=$chars" ; }

which would have the same effect as:

eval $(echo humpty dumpty | wc | { read lines words chars ; echo  
"lines=$lines ; words=$words ; chars=$chars" ; })

except that it wouldn't use stdout as its communication channel.

Why take half measures?


I believe ksh's method is to try to guess whether the parent shell  
wants to run the last section of the pipe.  I've had cases where it's  
guessed wrong so I'd rather let the programmer dictate what is to be  
kept and what to be dumped.  At the moment I favour the second of the  
above.  It's the most general solution.

Regards, Max