[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Procsub.tests on OSes using named pipes

From: Chet Ramey
Subject: Re: Procsub.tests on OSes using named pipes
Date: Sat, 15 Feb 2020 15:03:19 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/14/20 9:07 AM, CHIGOT, CLEMENT wrote:
> Hi everyone, 
> Actually, there is another bug when using named pipes, which might be related 
> to my previous patch.
> When using named pipe to write from the parent to the child process, the 
> child process is blocking in the open syscall of process_substitute() 
> (http://git.savannah.gnu.org/cgit/bash.git/tree/subst.c, line 5919).

The child blocks opening for read because the parent doesn't open it for
write. As you note below, that's how FIFOs work.

> I'm still investigating but it looks like the write end of the pipe is never 
> associated to the parent stdout. 

It's not supposed to be. That's not how process substitution works. Process
substitution expands to a file name. The process creating the process
substitution chooses what to do with it.

Therefore, when the child is trying to open the named pipe, it'll wait
forever, as said in the man of open: 
>>  FIFOs       
>>      Opening  the  read or write end of a FIFO blocks until the other end is 
>> also opened (by another
>>        process or thread).  See fifo(7) for further details.
> An easy way to reproduce it is to launch a script with: " moo() { echo 
> "ok";}; moo >(true)", you'll see an "ok" in your bash terminal and a 
> subprocess will be blocked in an open syscall. The fact that we are seeing 
> this "ok" means that the output of the parent process was never redirected to 
> the child. Am I right ? 

Well, you're right, the reason that the output of the parent didn't go to
the child is that nothing redirected it to the child. That might sound like
circular reasoning, but since process substitution expands to a file name,
the parent (in this case) process has to do something with it, usually via
redirection, to turn it into a file descriptor.

There's a case very similar to that in the test suite, which is supposed to
test a degenerate case (programmer error). What should the shell do if a
script creates a FIFO and doesn't do anything with it? Bash tries to detect
these sort of stray FIFOs and remove them.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]