Re: "echo | ps -j $(:) | cat | cat | cat" runs components in different process groups

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Tue, 17 Apr 2018 09:09:26 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Apr 17, 10:19am, Peter Stephenson wrote:
> } Subject: Re: "echo | ps -j $(:) | cat | cat | cat" runs components
> in diff }
> } On Mon, 16 Apr 2018 22:39:10 -0700
> } Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> } > So if, when we determine that "&" is the command separator, we
> could } > treat the command in the way the "time" prefix does, this
> would all } > work out without mangling execcmd_exec() and prefork().
> } 
> } That's good, I think that's probably worth doing.
> } 
> } I think it would be fine to change with a note about the
> } incompatibility.
> 
> Glad to hear that, however, I have very few clues about zsh wordcode
> (or in particular about how to put something into the wordcode back
> at the beginning of the command when we reach the separator at the
> end) so I'm not likely to be able to change this myself.

It's the whole structure of the parsing rather than the resulting word
code (though of course the effect is encoded there).  When "time" is
parsed we're at the level of a command, but instead of treating the
arguments as a command (which wouldn't work as we need to time am entire
pipeline), the parser recursively parses a nested pipeline (essentially
--- it's actually called "sublist2" in the parser because it can have
"coproc" or "!" in front, which also apply to the whole pipeline).  The
fork then happens at the level of the "time" command handling ---
because the "&" is parsed at the level of the list that includes the
time and its arguments, not the nested pipeline --- leaving the entire
pipeline after it to be run in the subshell from within the execution
environment for the time command (exectime()).

The ampersand is therefore parsed rather late to be able to see you need
this structure.  So it probably needs some other trick --- a different
list marker that causes a special null command akin to time to do the
fork, for example, as it's easy to update word code tokens when the
structure doesn't change.  The logic would then be within the exec code,
based on detecting the new token, rather than by restructuring the word
code.  Not actually very neat internally.

> There's also workers/42233 and related thread, if we're already going
> to be fiddling with wordcode.  (Limitations on the size of a script it
> is possible to zcompile.)

I think we demonstrated fairly conclusively that no one has the faintest
clue what's happening here.

pws