Re: Procsub.tests on OSes using named pipes

Hi everyone, It's been a while and I've forgotten to submit the solution I've found to avoid subprocesses stuck with named pipes. It's more a work around than a true fix, but I didn't manage to find a better solution. I haven't checked version 5.1 yet. Did many things changed regarding named

Re: Issue with Bash

riday, July 10, 2020 1:40 PM To: CHIGOT, CLEMENT Cc: bug-bash@gnu.org Subject: RE: Issue with Bash Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. Hi Clement, We have given it a try after applyin

Re: Issue with Bash

Hi Rishita, Could you try with BullFreeware's version, which have a slightly higher version (5.0.11 instead of 5.0) ? You can find it at http://www.bullfreeware.com/pkg?id=5740. If it's not working, I'll check what's wrong. Clément _

Re: Procsub.tests on OSes using named pipes

Hi all,  I might have found a way to avoid unkilled subprocesses when they are stuck in the open syscall. When the parent shell is killed, we can force it to open and close all the named pipes that it still have. It might be a bit harsh, but at least there is no unkilled processes anymore. I

Re: Procsub.tests on OSes using named pipes

I've just figured that the [ -e "$1" ] in the handler might cause some problems.  Sometimes, the named pipes isn't yet removed thus [ -e "$1" ] will be true and the return part won't be called. I'm not sure why it isn't removed directly, but it might just be how the AIX kernel is handling files

Re: Procsub.tests on OSes using named pipes

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

Re: Procsub.tests on OSes using named pipes

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

Procsub.tests on OSes using named pipes

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