Using zsh v5.8 on both MSYS2 and Cygwin and a plain vanilla shell (no dotfiles): If I run ls --color | less -R frequently I get zsh: done ls --color | zsh: suspended (tty output) less -R On rare occasions I can get this to happen with a simple ls | less but using the --color option seems to make it happen considerably more often. It happens quite frequently on MSYS2; it is harder to reproduce on Cygwin, but it does happen. This problem doesn't happen in bash. I don't know the origin of the problem, but I suspect list members will have insight. Alex
> 2021/01/19 4:08, agkozak@gmail.com wrote:
>
> Using zsh v5.8 on both MSYS2 and Cygwin and a plain vanilla shell (no
> dotfiles):
>
> If I run
>
> ls --color | less -R
>
> frequently I get
>
> zsh: done ls --color |
> zsh: suspended (tty output) less -R
>
> On rare occasions I can get this to happen with a simple
>
> ls | less
>
> but using the --color option seems to make it happen considerably more
> often. It happens quite frequently on MSYS2; it is harder to reproduce on
> Cygwin, but it does happen.
Yes, it happens quite frequently on MSYS2.
Has this been happening for a long time, or started to happen rather recently?
(my experience on MSYS2 is quite limited)
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 They seem to think they know exactly when the problem started, but I can't confirm that. The workaround of using a subshell seems to help, i.e. ls --color | (less -R) Alex -----Original Message----- From: Jun T <takimoto-j@kba.biglobe.ne.jp> Sent: Monday, January 25, 2021 5:50 PM To: zsh-workers@zsh.org Cc: Alexandros Kozak <agkozak@gmail.com> Subject: Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin) > 2021/01/19 4:08, agkozak@gmail.com wrote: > > Using zsh v5.8 on both MSYS2 and Cygwin and a plain vanilla shell (no > dotfiles): > > If I run > > ls --color | less -R > > frequently I get > > zsh: done ls --color | > zsh: suspended (tty output) less -R > > On rare occasions I can get this to happen with a simple > > ls | less > > but using the --color option seems to make it happen considerably more > often. It happens quite frequently on MSYS2; it is harder to reproduce > on Cygwin, but it does happen. Yes, it happens quite frequently on MSYS2. Has this been happening for a long time, or started to happen rather recently? (my experience on MSYS2 is quite limited)
> 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?
> 2021/01/27 19:14, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote: > > [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 */ Sorry, something went wrong with my MUA. the last two lines should read In this function, signals.c, line 543, it calls killpg(pn->pid, 0) /* pn->pid = pid_of_ls */ > Is there anyone familiar with Cygwin/MSIS2? Note for someone who tries to fix this problem on MSYS2: The current zsh git master does not compile well on MSYS2. At least you need to use % ./configure --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin The resulting zsh has a problem related with symlink (which is not supported on MSYS2), but it can be used for debugging purpose. Or you can use the patch below. This is a part of the patches used in MSYS2's zsh package. diff --git a/Src/zsh_system.h b/Src/zsh_system.h index 161b073b4..de1d675c4 100644 --- a/Src/zsh_system.h +++ b/Src/zsh_system.h @@ -852,6 +852,13 @@ extern short ospeed; # define IS_DIRSEP(c) ((c) == '/') #endif +#ifdef __MSYS__ +/* MSYS2 symlink() cannot create a symbolic link to a non existing file */ +# ifdef HAVE_SYMLINK +# undef HAVE_SYMLINK +# endif +#endif + #if defined(__GNUC__) && (!defined(__APPLE__) || defined(__clang__)) /* Does the OS X port of gcc still gag on __attribute__? */ #define UNUSED(x) x __attribute__((__unused__)) diff --git a/configure.ac b/configure.ac index 16dafac05..7eef49a8d 100644 --- a/configure.ac +++ b/configure.ac @@ -2706,7 +2706,7 @@ if test "x$aixdynamic" = xyes; then zsh_cv_sys_dynamic_strip_exe="${zsh_cv_sys_dynamic_strip_exe=yes}" zsh_cv_sys_dynamic_strip_lib="${zsh_cv_sys_dynamic_strip_lib=yes}" zsh_cv_shared_environ="${zsh_cv_shared_environ=yes}" -elif test "$host_os" = cygwin; then +elif test "$host_os" = cygwin -o "$host_os" = msys; then DL_EXT="${DL_EXT=dll}" ##DLLD="${DLLD=dllwrap}" DLLD="${DLLD=$CC}" @@ -2976,7 +2976,7 @@ if test "x$dynamic" = xyes; then if $strip_libldflags && test "$zsh_cv_sys_dynamic_strip_lib" = yes; then LIBLDFLAGS="$LIBLDFLAGS -s" fi - if test "$host_os" = cygwin; then + if test "$host_os" = cygwin -o "$host_os" = msys; then INSTLIB="install.cygwin-lib" UNINSTLIB="uninstall.cygwin-lib" fi @@ -3014,7 +3014,7 @@ AC_SUBST(SHORTBOOTNAMES) AC_SUBST(INSTLIB)dnl AC_SUBST(UNINSTLIB)dnl -if test "$host_os" = cygwin; then +if test "$host_os" = cygwin -o "$host_os" = msys; then EXTRAZSHOBJS="$EXTRAZSHOBJS zsh.res.o" fi
Just for record:
> 2021/01/19 4:08, agkozak@gmail.com wrote:
>
> Using zsh v5.8 on both MSYS2 and Cygwin and a plain vanilla shell (no
> dotfiles):
>
> If I run
>
> ls --color | less -R
>
> frequently I get
>
> zsh: done ls --color |
> zsh: suspended (tty output) less -R
This problem has been fixed in Cygwin 3.3.6-1 (released on Sep. 6).
The latest MSYS2 runtime already uses it.
If someone still has this problem on Cygwin/MSYS2 please let us know.
# Sorry for the slow fix; I forgot to report the problem to Cygwin.
# Once I reported it they _quickly_ fixed it.