* 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
* Re: Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin)
2021-01-27 2:44 Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin) 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 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-18 19:08 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-18 19:08 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
* 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
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-27 2:44 Possible ZSH bug involving piping ls to less (MSYS2 & Cygwin) agkozak
2021-01-27 10:14 ` Jun T
2021-01-28 10:42 ` Jun T
-- strict thread matches above, loose matches on Subject: below --
2021-01-18 19:08 agkozak
2021-01-26 1:49 ` Jun T
2022-09-13 8:49 ` 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).