[Bug] Unexpected process suspension

[Bug] Unexpected process suspension

[Rudi C]

[-- Attachment #1: Type: text/plain, Size: 125 bytes --]

mdoc-test () {

    sleep 0 | sleep 0
    cat}

echo start |VISUAL=vim command vipe|mdoc-test

# zsh: suspended (tty output)

Re: [Bug] Unexpected process suspension

[Daniel Shahaf]

Rudi C wrote on Tue, 12 May 2020 11:32 +0430:
> mdoc-test () {
> 
>     sleep 0 | sleep 0
>     cat}  
> 
> echo start |VISUAL=vim command vipe|mdoc-test
> 
> # zsh: suspended (tty output)

Reproduced in master and reduced to:

export EDITOR=ed
</dev/null vipe | { :|:; cat }

With EDITOR=cat it works.

Furthermore, trying to get vipe(1) out of the picture, I ran into:

% ed =(cat < /dev/null) | { :|:; cat }
zsh: suspended (tty input)  cat

Re: [Bug] Unexpected process suspension

[Roman Perepelitsa]

On Tue, May 12, 2020 at 1:50 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> % ed =(cat < /dev/null) | { :|:; cat }
> zsh: suspended (tty input)  cat

Might be related to workers/45647?

Roman.

Re: [Bug] Unexpected process suspension

[Daniel Shahaf]

Roman Perepelitsa wrote on Tue, 12 May 2020 13:53 +0200:
> On Tue, May 12, 2020 at 1:50 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > % ed =(cat < /dev/null) | { :|:; cat }
> > zsh: suspended (tty input)  cat  
> 
> Might be related to workers/45647?

Is either of these a regression?  If so, we can bisect them.

Re: [Bug] Unexpected process suspension

[Roman Perepelitsa]

On Tue, May 12, 2020 at 1:57 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Is either of these a regression?  If so, we can bisect them.

workers/45647 fails at HEAD and on zsh-5.4.2. Haven't tried anything else.

Roman.

Re: [Bug] Unexpected process suspension

[Stephane Chazelas]

2020-05-12 13:53:53 +0200, Roman Perepelitsa:
> On Tue, May 12, 2020 at 1:50 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > % ed =(cat < /dev/null) | { :|:; cat }
> > zsh: suspended (tty input)  cat
> 
> Might be related to workers/45647?
[...]

It looks very similar to workers/42512 (which had been
investigated, but not fully  resolved IIRC).

-- 
Stephane

Re: [Bug] Unexpected process suspension

[Bart Schaefer]

On Tue, May 12, 2020 at 12:03 AM Rudi C <rudiwillalwaysloveyou@gmail.com> wrote:
>
> mdoc-test () {
>
>     sleep 0 | sleep 0
>     cat}
>
> echo start |VISUAL=vim command vipe|mdoc-test
>
> # zsh: suspended (tty output)

Putting an interactive command in the middle of a pipeline is
generally not going to work.  Vim in particular is pretty aggressive
about trying to grab a terminal, which will result in processes
getting SIGTT* because they don't have foreground control of the
terminal they're trying to use.

Following Daniel's response I tried:

% </dev/null vim | { :|:; cat }
Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal

and although vim did open, upon exiting from it and returning to the
command line ZLE is very confused.  Even a hard reset of the terminal
emulator didn't fix it, the stty settings were hosed.

Re: [Bug] Unexpected process suspension

[Stephane Chazelas]

2020-05-12 10:38:38 -0700, Bart Schaefer:
> On Tue, May 12, 2020 at 12:03 AM Rudi C <rudiwillalwaysloveyou@gmail.com> wrote:
> >
> > mdoc-test () {
> >
> >     sleep 0 | sleep 0
> >     cat}
> >
> > echo start |VISUAL=vim command vipe|mdoc-test
> >
> > # zsh: suspended (tty output)
> 
> Putting an interactive command in the middle of a pipeline is
> generally not going to work.  Vim in particular is pretty aggressive
> about trying to grab a terminal, which will result in processes
> getting SIGTT* because they don't have foreground control of the
> terminal they're trying to use.
[...]

The thing is vim *should* be in the foreground, all the
processes started in pipeline should be in the same process
group which should be in foreground (so it gets
SIGINT/SIGQUIT/SIGTSTP upon ^C/^\/^Z, so it can read the
terminal, etc) but under some circumstances, zsh fails to put
some processes in that group, which is a bug.

$ </proc/self/stat awk '{print $5, $8}' >&2
127235 127235
$ </proc/self/stat awk '{print $5, $8; system("exec sleep 1")}'  >&2 | ps -o pid,pgid,comm
131569 131569
    PID    PGID COMMAND
 124948  124948 zsh
 131569  131569 awk
 131570  131569 ps
 131571  131569 sleep
$ </proc/self/stat awk '{print $5, $8}' >&2 | { :; }
127410 127410
$ </proc/self/stat awk '{print $5, $8}' >&2 | { : | :; }
127496 124948

In that latter case, awk is in a different process group
(127496) from the terminal foreground process group (124948
which here is the process group of the main shell process!).

-- 
Stephane

Re: [Bug] Unexpected process suspension

[Rudi C]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

Considering this bug (or a very similar variant) was reported before and
the issue just died a silent death, I think it's a good idea to create a
Github repo for tracking zsh issues. Github issue tracker is a lot better
than mailing lists, as things have a dichotomy of being  open/closed, and
can be labeled. It is harder for issues to die a silent death there. It is
also easier to contribute to that, and easier to unsubscribe (I don't think
one can unsubscribe from a mailing list post one participated in, as people
(wisely) use reply-all.).

On Wed, May 13, 2020 at 10:59 AM Stephane Chazelas <stephane@chazelas.org>
wrote:

> 2020-05-12 10:38:38 -0700, Bart Schaefer:
> > On Tue, May 12, 2020 at 12:03 AM Rudi C <rudiwillalwaysloveyou@gmail.com>
> wrote:
> > >
> > > mdoc-test () {
> > >
> > >     sleep 0 | sleep 0
> > >     cat}
> > >
> > > echo start |VISUAL=vim command vipe|mdoc-test
> > >
> > > # zsh: suspended (tty output)
> >
> > Putting an interactive command in the middle of a pipeline is
> > generally not going to work.  Vim in particular is pretty aggressive
> > about trying to grab a terminal, which will result in processes
> > getting SIGTT* because they don't have foreground control of the
> > terminal they're trying to use.
> [...]
>
> The thing is vim *should* be in the foreground, all the
> processes started in pipeline should be in the same process
> group which should be in foreground (so it gets
> SIGINT/SIGQUIT/SIGTSTP upon ^C/^\/^Z, so it can read the
> terminal, etc) but under some circumstances, zsh fails to put
> some processes in that group, which is a bug.
>
> $ </proc/self/stat awk '{print $5, $8}' >&2
> 127235 127235
> $ </proc/self/stat awk '{print $5, $8; system("exec sleep 1")}'  >&2 | ps
> -o pid,pgid,comm
> 131569 131569
>     PID    PGID COMMAND
>  124948  124948 zsh
>  131569  131569 awk
>  131570  131569 ps
>  131571  131569 sleep
> $ </proc/self/stat awk '{print $5, $8}' >&2 | { :; }
> 127410 127410
> $ </proc/self/stat awk '{print $5, $8}' >&2 | { : | :; }
> 127496 124948
>
> In that latter case, awk is in a different process group
> (127496) from the terminal foreground process group (124948
> which here is the process group of the main shell process!).
>
> --
> Stephane
>

A bug tracker (was: Re: [Bug] Unexpected process suspension)

[Daniel Shahaf]

Rudi C wrote on Thu, 21 May 2020 03:02 +0430:
> Considering this bug (or a very similar variant) was reported before and
> the issue just died a silent death, I think it's a good idea to create a
> Github repo for tracking zsh issues. Github issue tracker is a lot better
> than mailing lists, as things have a dichotomy of being  open/closed, and
> can be labeled. It is harder for issues to die a silent death there.

I'm not opposed to adding a proper issue tracker, but github is not the
only fish in the sea; it is one option among many.

IIRC, last time this was discussed, it was requested to have
bidirectional integration with the mailing list.  Do I recall correctly?

If we opt for an issue tracker, there'll be the question of whether
we'll use the issue tracker to receive/triage bug reports, or keep
triage on the mailing lists like today and only use the tracker to
record known defects and conclusions of discussions.  The latter would
be the smaller change compared to the status quo.

Another way to solve this is to have a "bug reports manager", who would
be a volunteer who'd scan the lists regularly — say, once a week — for
any bug report threads that have petered out without a solution, and
ping those.  (The volunteer needn't be a developer.)  I filled a similar
role myself, years ago at $OTHERPROJECT.  Compare
https://producingoss.com/en/share-management.html#manager-is-not-owner
(particularly its first subsection, read with s/patch/bug report/g).

Finally, I have been using Etc/BUGS in git to track bugs.  If someone'd
like to add an entry there for this set of related bugs, please do.

> It is also easier to contribute to that, and easier to unsubscribe
> (I don't think one can unsubscribe from a mailing list post one
> participated in, as people (wisely) use reply-all.).

No, it's not possible to unsubscribe from being directly Cc'd, but the
responses generally peter out after a few days, and there are plenty of
ways to deduplicate or otherwise flag responses that were Cc'd both to
oneself and to the list.

Cheers,

Daniel

> On Wed, May 13, 2020 at 10:59 AM Stephane Chazelas <stephane@chazelas.org>
> wrote:
> 
> > 2020-05-12 10:38:38 -0700, Bart Schaefer:  
> > > On Tue, May 12, 2020 at 12:03 AM Rudi C <rudiwillalwaysloveyou@gmail.com>  
> > wrote:  
> > > >
> > > > mdoc-test () {
> > > >
> > > >     sleep 0 | sleep 0  
> > > >     cat}  
> > > >
> > > > echo start |VISUAL=vim command vipe|mdoc-test
> > > >
> > > > # zsh: suspended (tty output)  
> > >
> > > Putting an interactive command in the middle of a pipeline is
> > > generally not going to work.  Vim in particular is pretty aggressive
> > > about trying to grab a terminal, which will result in processes
> > > getting SIGTT* because they don't have foreground control of the
> > > terminal they're trying to use.  
> > [...]
> >
> > The thing is vim *should* be in the foreground, all the
> > processes started in pipeline should be in the same process
> > group which should be in foreground (so it gets
> > SIGINT/SIGQUIT/SIGTSTP upon ^C/^\/^Z, so it can read the
> > terminal, etc) but under some circumstances, zsh fails to put
> > some processes in that group, which is a bug.
> >
> > $ </proc/self/stat awk '{print $5, $8}' >&2
> > 127235 127235
> > $ </proc/self/stat awk '{print $5, $8; system("exec sleep 1")}'  >&2 | ps
> > -o pid,pgid,comm
> > 131569 131569
> >     PID    PGID COMMAND
> >  124948  124948 zsh
> >  131569  131569 awk
> >  131570  131569 ps
> >  131571  131569 sleep
> > $ </proc/self/stat awk '{print $5, $8}' >&2 | { :; }
> > 127410 127410
> > $ </proc/self/stat awk '{print $5, $8}' >&2 | { : | :; }
> > 127496 124948
> >
> > In that latter case, awk is in a different process group
> > (127496) from the terminal foreground process group (124948
> > which here is the process group of the main shell process!).
> >
> > --
> > Stephane
> >  

Re: A bug tracker (was: Re: [Bug] Unexpected process suspension)

[Bart Schaefer]

On Wed, May 20, 2020 at 8:33 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Rudi C wrote on Thu, 21 May 2020 03:02 +0430:
> > Github issue tracker is a lot better
> > than mailing lists, as things have a dichotomy of being  open/closed, and
> > can be labeled. It is harder for issues to die a silent death there.
>
> I'm not opposed to adding a proper issue tracker, but github is not the
> only fish in the sea; it is one option among many.

Indeed, if we're going to continue hosting the git repository on
SourceForge, then reviving some kind of use of the bug tracker there
would seem to make more sense than github.

Re: A bug tracker (was: Re: [Bug] Unexpected process suspension)

[Oliver Kiddle]

Daniel Shahaf wrote:
> Finally, I have been using Etc/BUGS in git to track bugs.  If someone'd
> like to add an entry there for this set of related bugs, please do.

As I've just been catching up on the list having had little time
recently, here's a collection of some of the outstanding bugs:

44133 debian #924736 (partial patch in 44134) three setopts following `    #`
44850 terminal issues with continuation markers
45422 _arguments !-x !+x: this is on my TODO list
45482 print -v with multibyte characters
45568 repeat-count "illegal character"
  this can't be too hard given it is the meta range of characters
  Incidentally, I don't like the use of "illegal" in error messages.
  Perhaps this is a UK/US difference but to me "illegal" implies
  actually against the law.
45656 -o nobanghist -o emacs segfaults
users/24765 -direct terminals. Not a bug as such but we may need to do
  something if -direct values in TERM are ever common
45830 _gpg, I can't reproduce either.

There are also some outstanding patches:

45393/45396 avoid lseek(2) calls. Doesn't this just need a quick verification?
  I've had some dealings with the patch author in relation to i3 and would
  trust him even without looking at the patch details.
45768 This looks distinctly similar to the above.
45837 Stephane's patch for 45828
45007 has_colors in configure.ac. This didn't reproduce on any of my systems
  but I've just noticed that the originator has a gentoo.org address which might
  provide some extra clues.

There was a recent (45778) reminder about 44525 which is by Roman.

I don't care enough about different bug tracking methods to get much
involved in that discussion. The mailing list perhaps intimidates
potential newcomers nowadays which is not ideal. But it has advantages
like the single archive that can be offline. Integration with a list is
fine if you don't get spammed. All too often every little status change
generates a mail.

Oliver

Re: A bug tracker (was: Re: [Bug] Unexpected process suspension)

[Daniel Shahaf]

Oliver Kiddle wrote on Thu, 21 May 2020 15:39 +0200:
> Daniel Shahaf wrote:
> > Finally, I have been using Etc/BUGS in git to track bugs.  If someone'd
> > like to add an entry there for this set of related bugs, please do.  
> 
> As I've just been catching up on the list having had little time
> recently, here's a collection of some of the outstanding bugs:
> 

Thanks!  Committed with edits.