Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: zsh 5.6 regression: a pipe sometimes yields a TTOU signal



On Wed, 5 Sep 2018 12:55:10 +0200
Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> On 2018-09-05 11:03:54 +0100, Peter Stephenson wrote:
> > With
> > 
> > (echo mercurial) | gr mercurial
> > 
> > I always get
> > 
> > zsh: suspended (tty output)  pager-wrapper grep --color=always --line-buffered -E mercurial  
> 
> Or just with:
> 
>   (echo foo) | { grep foo | less -+c -FX }
> 
> > This isn't going to be fixed quickly (or, quite likely, at all without
> > creating different knock-on effects, as changes here always do).  
> 
> Is there any reason why this changed since zsh 5.5.1? If a new feature
> is the cause, couldn't it be reverted until this is fixed?

Bizarrely, yes there is actually a reason the code changed(!)  There are
no new features in this area and the last obvious related change I can
see was in May, although I don't know if that's causing this or not ---
it's not obvious why it would cause this, but working with multiple
processes is subtle.

(Hope the following doesn't appear grumpy, I'm just trying to be
realistic about this.)

Any changes were there to fix long-standing problems in the combination
of pipes and builtin structures.  This has always been buggy and the
code is a total nightmare.  Arguably we are doing too much work --- this
dates from the late 90s, when Sven put in some extremely clever but a
changes to allow job control with shell constructs to work a
bit more naturally: they're extremely clever but a bit brittle and a lot
hard to understand.  I don't think there have been any new *features*
since then, just gradual improvements in the things we know how to
test.

The code has evolved in such away that I don't think going back is
sensible.  It's never been perfect and --- given that people aren't
doing enough testing between releases, as the emergence of the present
issue shows --- arbitrarily backing off changes until it sort-of vaguely
works is just asking for trouble.  We *know* this will expose bugs.

The choices I can see are:

1. Wait for me to do something about it on my own time and no, you don't
get to hassle me about it.  I'm not promising a date, I'm just saying
it's quite likely if no one else looks at it I prbably will at some
point but the rest of my life isn't going to stop.  As it's reproducible
it's probably hours work rather than days if I get the chance to look.

2. Someone else gets a go.  Whoopee!  I'm very glad to give as many
pointers as you need.

3. Just lump it for the time being and test the pre-release better next
time.  With races like this we need everybody trying out all their
awkward cases.  (Ideally we need lots of people using the top of tree,
in fact.)

Cheers
pws



Messages sorted by: Reverse Date, Date, Thread, Author