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
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
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
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 proce
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 EN
> > 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
> 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 t
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
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
