Re: Procsub.tests on OSes using named pipes

[Chet Ramey]

On 2/13/20 5:00 AM, CHIGOT, CLEMENT wrote:
> Hi, 
> 
> procsub.tests is failing on OSes using named pipes (like AIX). 
> As far as I understand, with named pipes, the temporary file (sh-np*) is 
> suppressed once it has been read, therefore every attempts to read the same 
> input will fail with ENOENT. It seems to be the case in "count_lines" 
> function. 

Pretty much true. Once the data in the pipe has been read and the process
writing to (or reading from) the named pipe has terminated, the shell reaps
the process and removes the named pipe. We don't want to leave stray FIFOs
in the file system.

(That's the real problem with using FIFOs for this: they exist in the file
system and aren't private to the process like file descriptors and
/dev/fd.)

However, the handler for named pipes has been commented and I haven't found
why. Is there any reason behind that ? If no, here is a patch fixing
procsub.tests.

It probably should be. Thanks for the patch.

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

Re: Procsub.tests on OSes using named pipes

[Chet Ramey]

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.

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