zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: <zsh-workers@zsh.org>
Subject: Re: zsh 5.6 regression: a pipe sometimes yields a TTOU signal
Date: Wed, 5 Sep 2018 13:53:19 +0100	[thread overview]
Message-ID: <20180905125320eucas1p196ef7dfbb8ce5f76d084021ae358ac54~RghsfbuZ12275022750eucas1p1f@eucas1p1.samsung.com> (raw)
In-Reply-To: <20180905105510.GA2116@cventin.lip.ens-lyon.fr>

On Wed, 5 Sep 2018 12:55:10 +0200
Vincent Lefevre <vincent@vinc17.net> 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

  parent reply	other threads:[~2018-09-05 12:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180905091407epcas1p1ff78da39bfd4f3e4201f467683288a7b@epcas1p1.samsung.com>
2018-09-05  9:03 ` Vincent Lefevre
2018-09-05 10:03   ` Peter Stephenson
2018-09-05 10:55     ` Vincent Lefevre
2018-09-05 12:22       ` Vincent Lefevre
2018-09-05 13:17         ` Vincent Lefevre
2018-09-05 13:37           ` Vincent Lefevre
2018-09-05 14:40             ` Peter Stephenson
2018-09-06 11:40               ` Vincent Lefevre
2018-09-06 12:26                 ` Vincent Lefevre
2018-09-06 12:36                   ` Vincent Lefevre
2018-09-06 12:55                     ` Peter Stephenson
2018-09-05 12:53       ` Peter Stephenson [this message]
2018-09-05 13:21       ` Peter Stephenson

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='20180905125320eucas1p196ef7dfbb8ce5f76d084021ae358ac54~RghsfbuZ12275022750eucas1p1f@eucas1p1.samsung.com' \
    --to=p.stephenson@samsung.com \
    --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).