zsh-workers
 help / color / mirror / code / Atom feed
* Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)
@ 2021-01-18 19:08 agkozak
  2021-01-26  1:49 ` Jun T
  2022-09-13  8:49 ` Jun T
  0 siblings, 2 replies; 6+ messages in thread
From: agkozak @ 2021-01-18 19:08 UTC (permalink / raw)
  To: zsh-workers

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 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)
  2021-01-18 19:08 Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin) agkozak
@ 2021-01-26  1:49 ` Jun T
  2022-09-13  8:49 ` Jun T
  1 sibling, 0 replies; 6+ messages in thread
From: Jun T @ 2021-01-26  1:49 UTC (permalink / raw)
  To: zsh-workers; +Cc: Alexandros Kozak


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)
  2021-01-18 19:08 Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin) agkozak
  2021-01-26  1:49 ` Jun T
@ 2022-09-13  8:49 ` Jun T
  1 sibling, 0 replies; 6+ messages in thread
From: Jun T @ 2022-09-13  8:49 UTC (permalink / raw)
  To: zsh-workers; +Cc: Alexandros Kozak

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.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)
  2021-01-27 10:14 ` Jun T
@ 2021-01-28 10:42   ` Jun T
  0 siblings, 0 replies; 6+ messages in thread
From: Jun T @ 2021-01-28 10:42 UTC (permalink / raw)
  To: zsh-workers


> 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
 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)
  2021-01-27  2:44 agkozak
@ 2021-01-27 10:14 ` Jun T
  2021-01-28 10:42   ` Jun T
  0 siblings, 1 reply; 6+ messages in thread
From: Jun T @ 2021-01-27 10:14 UTC (permalink / raw)
  To: zsh-workers; +Cc: Alexandros Kozak


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)
@ 2021-01-27  2:44 agkozak
  2021-01-27 10:14 ` Jun T
  0 siblings, 1 reply; 6+ messages in thread
From: agkozak @ 2021-01-27  2:44 UTC (permalink / raw)
  To: zsh-workers; +Cc: 'Jun T'

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)



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-09-13  8:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-18 19:08 Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin) agkozak
2021-01-26  1:49 ` Jun T
2022-09-13  8:49 ` Jun T
2021-01-27  2:44 agkozak
2021-01-27 10:14 ` Jun T
2021-01-28 10:42   ` Jun T

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).