Re: redirection inside a process-substitution

[Helmut Karlowski]

Am 24.08.2016, 18:00 Uhr, schrieb Chet Ramey:

> > echo > >(echo 3 1>&3)
> > echo +++++
> > cat tb.err
> > echo -----
> > wait
> >
> > I get in bash:
>
> Strange.  I get
>
> +++++
> 1
> -----
> +++++
> 11
> -----
> +++++
> -----
> 2
> +++++
> 2
> 3
> -----
>
> on Mac OS X and RHEL 6.  I'm not sure why the last redirection (the one
> with just process substitution and not 3>&1) doesn't cause the file to
> be truncated, or the file pointer to be adjusted, but the trace is the
> same in all cases.

I think because the redirection goes to a process, not a file.

> > in zsh (sometimes, sometimes it prints nothing):
>
> I speculate that this has to do with something that zsh does to force
> appending, whether that's lseek or something else, other than the fact
> that zsh doesn't seem to use /dev/fd at all (I think it just straight
> uses pipes).  Bash doesn't do anything special with tb.err after opening

zsh uses temp-files for all process-substitution, which limits it's
features but is easier to do.

In my test bash got killed by SIGPIPE. Maybe you can reproduce it with:

#trap 'echo PIPE' PIPE
{ sleep 1; echo bla; } > >(echo r4 )
echo ---------------

When I uncomment the first line bash gets into real trouble:

obash bashbug.txt
bashbug.txt: line 3: echo: write error: Broken pipe
bashbug.txt: line 1: echo: write error: Broken pipe
bashbug.txt: line 1: echo: write error: Broken pipe

....

endlessly.


-Helmut


--