Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: problem with 'ls | less' shell function
- X-seq: zsh-workers 50798
- From: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: problem with 'ls | less' shell function
- Date: Thu, 20 Oct 2022 17:26:40 +0100 (BST)
- Archived-at: <https://zsh.org/workers/50798>
- Importance: Normal
- In-reply-to: <CAH+w=7Y7X4AvdzxU1sdHUyT6oLR7zcW8qXoQEHsm6ubW=9kUqw@mail.gmail.com>
- List-id: <zsh-workers.zsh.org>
- References: <Y00dwVyJTYUk2QWn@yt.nih.at> <CAHYJk3SGs_+poYGwU+JYQBh4rQe2bf9SeuYGTpdLvfgSJSybGw@mail.gmail.com> <Y012dIpfGmPqj2Tz@yt.nih.at> <Y0+0olfiaDplISd7@localhost> <CAH+w=7Y7X4AvdzxU1sdHUyT6oLR7zcW8qXoQEHsm6ubW=9kUqw@mail.gmail.com>
> On 20/10/2022 01:10 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
>
> On Wed, Oct 19, 2022 at 1:28 AM <zsugabubus@national.shitposting.agency> wrote:
> >
> > 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.
>
> First sentence partly wrong, second sentence right.
>
> When a shell function is suspended with ^Z, the parent shell forks
> again to create a process for the shell function, but doesn't change
> the process group of the pipeline. When "fg" brings the shell
> function process back, that process is made group leader, but it then
> needs to reset the group leader again to the pid of its own foreground
> job, which it does not ... or, conversely, upon suspend the parent
> shell needs to avoid changing the group leader of the new process.
>
> At this point I'm not sure which of those needs to happen or where.
> It's all in or around the call to addproc() at exec.c line 1734.
I'd be quite surprised if you didn't need to be looking at
this comment at line 1872. This isn't necessarily the same thing
but must surely be related...
/*
* At this point, we used to attach this process
* to the process group of list_pipe_job (the
* new superjob) any time that was still available.
* That caused problems in at least two
* cases because this forked shell was then
* suspended with the right hand side of the
* pipeline, and the SIGSTOP below suspended
* it a second time when it was continued.
*
* It's therefore not clear entirely why you'd ever
* do anything other than the following, but no
* doubt we'll find out...
*/
pws
Messages sorted by:
Reverse Date,
Date,
Thread,
Author