Unbuffered pipes: cases to be supported

[Dale R. Worley]

The cases I've found where bash allocates a pipe, and thus an unbuffered
pipe may be wanted, are:

1. pipelines:  command1 | command2

By analogy with the cases below, I think the demo should be amended to
use this syntax:

    command1 >>| command2

and the parallel for redirecting both stdout and stderr:

    command1 >>|& command2

This adds these productions to parser.y:

    pipeline:   pipeline GREATER_GREATER_BAR newline_list pipeline
            |   pipeline GREATER_GREATER_BAR_AND newline_list pipeline

and parallel changes to read_token().

This notation has the problem that it looks like ">|", which has a
completely different meaning (it's OK to write over an existing file).
But I think the risks to users are low, as trying to use ">>|" as an
append-redirection would cause the next word to be interpreted as a
command name, and it would be unlikely to be executable.

2. command substitution:  command1 arg arg <( command2 ) arg
                          command1 arg arg >( command2 ) arg

In the first case, you may want output from command2 to be unbuffered.
In the second case, you may want output from command1 to the stream it
opens based on the substituted argument to be unbuffered.

A reasonably evocative syntax for these is:

    command1 arg arg <<( command2 ) arg
    command1 arg arg >>( command2 ) arg

Implementing this is messier because the reading of "words" is all hand
coded.  But the initial parsing is in read_token_word(), and the
processing starts with extract_process_subst() in subst.c.

This case also shows that we need to be able to pass to a command
indications to not buffer multiple dev/inos, since one can write:

    command1 >>( command2 ) >>( commnd3 )

and command1 needs to be told to not buffer both pipes.

3. coprocesses:  coproc [NAME] command

This creates a pipe from bash to the stdin of command and a pipe from
the stdout of command to bash, either or both of which could be
unbuffered.

I was thinking that an intuitive syntax would be:

    coproc >> [NAME] command
    coproc << [NAME] command
    coproc >> << [NAME] command

but that doesn't work at all -- command can start with a redirection.
Perhaps the indicators can be put at the end of the statement:

    coproc [NAME] command >>
    coproc [NAME] command <<
    coproc [NAME] command >> <<

since a command can't end with a redirection operator and can't be
followed by a word.

Dale