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
--
