Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)

[Jun T <takimoto-j@kba.biglobe.ne.jp>]

> 2021/01/27 11:44, agkozak@gmail.com wrote:
> 
> I'm pretty sure it's been happening intermittently for quite a while, but I
> couldn't say for sure when it started. Sorry.
> 
> I found a discussion on GitHub of a similar problem where git was being
> piped to tig:
> 
>    https://github.com/jonas/tig/issues/951

[1] This github issue suggests the problem has started in zsh-5.6, and 
I have confirmed that zsh-5.5.1 does not have this problem.

[2] My Widows10/Cygwin (or MSYS2) is running in a virtual machine (on macOS).
If I allocate only one CPU core to the virtual machine, then problem does
not occur.

[3] I used strace command to find the following:

When ls exits, the main zsh gets SIGCHLD and calls wait_for_processes().
In this function, signals.c, line 543, it calls
          /* pn->pid is the pid of ls */
When the problem occurs, this returns -1 with errno==ESRCH.
So the parent zsh thinks that there is no process left in the process group
(leader = ls) and reclaims the control terminal.

When killpg(pn->pid, 0) is called, the subshell for less has already forked,
and it has already called
    setpgrp(0, pid_of_ls)
But fork/exec in Cygwin (or MSYS2) is very slow (emulated) and, when the
problem occurs, exec(less) has not yet "completed".
It *seems* that killpg(pid_of_ls, 0) fails if the subshell is in the middle
of exec(less).

Is there anyone familiar with Cygwin/MSIS2?