On 2011-12-01, Ian Fitchet <
ian.f...@gmail.com> wrote:
> On Nov 26, 5:02 pm, Kaz Kylheku <
k...@kylheku.com> wrote:
>> I seriously doubt Barry is confused by tty output, like some newbie.
>
> Indeed so and my apologies to Barry. I wanted to use his concise
> example but should have clearly directed my subsequent answer to
> Alexis.
>
> Perhaps I have missed a subtle semantic.
>
>> It's not a file name, but the name of a pipe-like object
>
> Indeed, hence we have
>
> $ echo foo > *word*
> $ echo foo | *cmd*
>
> The semantics of the pipeline are that the commands individually run
> to completion before the pipeline is complete.
Therefore, it would be desireable if this would continue to hold
if we instead express it is :
echo foo > >(*cmd*)
All commands run to completion: echo and *cmd*.
> The semantics of IO redirection is that the command completes when
> its output to *word* completes (ie *word* has consumed all of the
> command's output).
This is the same as "commands individually run to completion before the
pipeline is complete". Only, you just have one command (*word* is not a
command).
> Should echo block until the reader of an arbitrary
> fifo completes?
No because in echo foo | *cmd*, it does not do so.
The standard input pipe of *cmd* satisfies the definition of "arbitrary fifo".
>> The process
>> on the other side of that pipe-thing is being leaked out of the command. That
>> is a bug.
>
> I don't understand what you mean by the process being leaked.
Leaked means that something has escaped beyond the scope of its
proper duration.
This is the issue exhibited by the Bash implementation of the concept.
The process continues to execute and all of its visible side effets
happen beyond the "fence" that should divide consecutive commands.
>> In effect the syntax > >cmd is the same as | cmd, and the shell
>> should be free to optimize it that way at the abstract syntax level.
>
> I'm happy for "> >(cmd)" to be a synonym for "| cmd" if that's how
> it's meant to be although it seems superfluous to have two distinct
> syntaxes.
Sure, and likewise since we can do both x + x and 2 * x, let's
throw away one of them.
We must combat redundancy by fighting against it! :)
>> I.e. if the /dev/whatever hidden pathname is the operand of a redirection, then
>> it is pointless and can be turned into a pipe going directly to the target
>> process.
>
> On the other hand, having some mechanism to substitute a name for a
> cmd has proven quite useful where other commands only accept files:
>
> $ diff <(cmd1) <(cmd2)
Well, no kidding; the pipe-like object isn't the operand of a redirection here.
You're just re-iterating that this syntax does something that you can't
easily do otherwise, which is obvious.