From: zsugabubus@national.shitposting.agency
To: Thomas Klausner <wiz@gatalith.at>
Cc: zsh-workers@zsh.org
Subject: Re: problem with 'ls | less' shell function
Date: Wed, 19 Oct 2022 10:26:10 +0200 [thread overview]
Message-ID: <Y0+0olfiaDplISd7@localhost> (raw)
In-Reply-To: <Y012dIpfGmPqj2Tz@yt.nih.at>
On Mon, Oct 17, 2022 at 05:36:20PM +0200, Thomas Klausner wrote:
> On Mon, Oct 17, 2022 at 04:50:20PM +0200, Mikael Magnusson wrote:
> > On 10/17/22, Thomas Klausner <wiz@gatalith.at> wrote:
> > > Hi!
> > >
> > > I recently noticed a problem in zsh 5.9 (as built from pkgsrc) on
> > > NetBSD 9.99.100. Since I didn't notice it before it could be related
> > > to a change in NetBSD (I'm following the latest version), but I've
> > > been told that the issue can be reproduced on Ubuntu 19.04 and FreeBSD
> > > 13.1 too; but not in zsh 5.8.1, nor in most other shells though.
> > >
> > > The discussion on the NetBSD mailing list can be read in this thread:
> > > https://mail-index.netbsd.org/current-users/2022/10/12/msg043076.html
> > > but I'll summarize the issue I see in zsh here.
> > >
> > > I have a shell function I've been using for ages:
> > >
> > > dir() { ls -al "$@" | less; }
> > >
> > > Recently, when I tried suspending this with CTRL-Z and then resuming
> > > it with 'fg', I get:
> > >
> > > $ dir
> > > (CTRL-Z)
> > > zsh: done ls -al "$@" |
> > > zsh: suspended
> > > $ fg
> > > [1] + done ls -al "$@" |
> > > continued
> > > zsh: done ls -al "$@" |
> > > zsh: suspended (tty output)
> > > zsh: done ls -al "$@" |
> > > zsh: suspended (tty output)
> > >
> > > The same thing works in NetBSD's ksh:
> > >
> > > $ fg
> > > ls -al "$@" | less
> > > (CTRL-Z)
> > > [1] + Done ls -al "$@" |
> > > Stopped less
> > >
> > > or in bash
> > >
> > > $ fg
> > > ls -al "$@" | less
> > > (CTRL-Z)
> > >
> > > [1]+ Stopped ls -al "$@" | less
> > >
> > > If I use '/bin/ls' in the shell function instead of 'ls', it works
> > > fine.
> > >
> > > Any ideas what the issue could be?
> >
> > The last bit implies that 'ls' is an alias or function, can you check
> > the output of 'which ls'?
>
> No, it isn't:
>
> $ which ls
> /bin/ls
> $ type ls
> ls is /bin/ls
>
> Compare to
>
> $ type ll
> ll is an alias for ls -al
> $ type dir
> dir is a shell function from /home/wiz/.zshrc
>
> But I take back the statement that it works with /bin/ls in the dir
> function definition, it shows the same broken behaviour. Not sure why
> I thought it worked before, sorry for that red herring.
> Thomas
>
I think what happens is that zsh fails to correctly set the foreground
process group in `fg`. `less` is not in the foreground pgrp that's why
it immediately gets suspended by SIGTTIN after it receives SIGCONT.
In this example it is more obvious that `sleep` is not in the
foreground pgrp (confirm with ps):
$ f(){echo|sleep 60}
$ f
^Z
$ fg
^Z^Z^C^C^C^C^C^\
15bf8ace168a86d0fae90b10e9f706baddd4c0bf is the first bad commit
50134: Tweak process group handling to prevent unkillable pipelines
--
zsugabubus
next prev parent reply other threads:[~2022-10-19 8:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 9:17 Thomas Klausner
2022-10-17 14:50 ` Mikael Magnusson
2022-10-17 15:36 ` Thomas Klausner
2022-10-19 8:26 ` zsugabubus [this message]
2022-10-19 10:04 ` Jun T
2022-10-19 13:36 ` Jun. T
2022-10-20 0:10 ` Bart Schaefer
2022-10-20 16:26 ` Peter Stephenson
2022-10-21 5:45 ` Jun T
2022-10-21 7:40 ` Jun T
2022-10-21 21:22 ` Bart Schaefer
2022-10-21 21:24 ` Bart Schaefer
2022-10-22 23:22 ` Bart Schaefer
2022-10-22 23:43 ` Bart Schaefer
2022-11-03 23:10 ` Bart Schaefer
2022-11-04 6:09 ` [PATCH] " Bart Schaefer
2022-11-04 15:10 ` [PATCH] " Jun T
2022-11-05 0:09 ` Bart Schaefer
2022-11-06 19:12 ` Bart Schaefer
2022-11-07 8:43 ` Jun T
2022-11-07 19:33 ` Bart Schaefer
2022-11-07 19:44 ` Roman Perepelitsa
2022-11-08 0:46 ` Bart Schaefer
2022-11-08 0:44 ` Bart Schaefer
2022-11-08 5:03 ` Bart Schaefer
2022-11-09 5:03 ` Bart Schaefer
2022-10-19 9:33 ` Jun T
2022-10-19 10:01 ` Jun T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0+0olfiaDplISd7@localhost \
--to=zsugabubus@national.shitposting.agency \
--cc=wiz@gatalith.at \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).