Re: Sub shell mit pipes

[Enrique Perez-Terron]

On Wed, 2004-08-11 at 22:50, Chet Ramey wrote:
> Paul Jarc wrote:
> 
> > Enrique Perez-Terron <enrio@online.no> wrote:
> > 
> >>Is there any formal requirement dictating that the 'while' statement
> >>shall be executed in a sub-shell?
> > 
> > 
> > Not that I can find, but I imagine it makes the code simpler.
> 
> Think job control.  Different elements of pipelines running in
> different process groups makes job control impossible.
> 
> Posix has traditionally required that each element of a pipeline run
> in a `subshell environment', but allowed the ksh behavior as an
> extension.

The suggested syntax

  command_1 | exec | command_2

would suffer from the same problems wrt. job control. In particular,

  command_1 | exec | command_2 &

would become meaningless, unless it is implemented as

  command_1 | {
    rest of the script
  } | command_2 &

which means that the rest of the script is run in a subshell and in a
process group. If the rest of the script comes from a tty, the user will
have to hit ^D to generate an end-of-file, before anything happens.

What should happen if the user presses ^Z ? 

Probably the same as happens today if the user "types command_1 | {"
(enter).

Perhaps it is more natural to treat ... | exec | ...
as syntactic sugar for

  exec < <(command_1) > >(command_2),

and rather document how this is handled wrt job control.

In any case, the combinations < <(..) and > >(..)  should be implemented
using pipes and so be available on all architectures supporting pipes,
even if named pipes are not available. Is this the case already?

What about users typing 

  cmd1 | exec | cmd2 | exec | cmd 3 ?

This must be tested for and generate an ambiguous redirection error,
just like

  exec < <(cmd1) > >(cmd2) < <(cmd2) > >(cmd3)

Any thoughts?

-Enrique