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

[Peter Stephenson <p.stephenson@samsung.com>]

I've now been testing with

echo foo | { : | more }

though the exact form isn't going to be important.

My theory is the following is happening:

- Process "echo foo" gets control of the terminal.

- The shell forks ":".  This is group leader for the new pipeline but
doesn't get control of the terminal. Note the { ... } is directly under the control of the main shell, as as is the "echo foo | ..." pipeline.  We
are in the world of nested pipelines.  (Remember "Rimmerworld"? Yes,
exactly.)

- "echo" exits

- The shell looks for a process to attach the tty to and finds ":"
which is currently group leader.

- ":" exits leaving the process group without a leader.

- "more" is forked but doesn't get the TTY because nobody knows no one
ain't got it.  This is different from the case where there's no nested
pipeline.

As evidence, replacing ":" by "sleep 0.01" eliminates the problem (or
"zselect -t 1" which is equivalent --- but it's not just builtins, you
can put a "cat" there, but please don't swing it as you haven't got room,
and the bug still happens).  So I think there's some problem with the way
transferring group leadership (the job gleader struct field) interacts with
attaching the TTY (the call to attachtty()) when we've got a nested
pipeline.

Please tell me someone finds this an interesting problem...

pws