On 3/20/21 3:15 PM, Michael Felt wrote:
Scraping through this - thanks for the lessons aka explanations.
On 18/03/2021 16:08, Chet Ramey wrote:
On 3/18/21 5:53 AM, Michael Felt wrote:
Yes, something to test. Thx. The ojdk scenario is: /usr/bin/printf >
>(tee -a stdout.log) 2> >(tee -a stderr.log).
So, yes, in this case it is working because printf is the parent -
(which I never seemed to find actually calling open() of the file. It
seems to be using the fd opened by the child - in a magical way).
It's the redirection. The shell does the open, since the filename resulting
from process substitution is the target of a redirection operator. This is
a common idiom -- so common, in fact, that people have interpreted it to
mean that the entire `> >(xxx)' is a single operator.
However, the shell expands redirections in the child process it forks to
exec printf, so that child shell is what does the process substitution.
That might be the problem here.
I think that ended up being the problem. When the process substitution is
used in a redirection, and the command is a normal command found in the
file system and executed with execve(2), there's nothing left to remove
the FIFOs when the command completes.
The best solution is for the shell to remove the FIFOs created as part of
redirection (they've already been opened) before calling execve.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
