* Non-forking command substitution
[not found] ` <21586f92-9a78-419c-84e5-f203a6f069b6@app.fastmail.com>
@ 2022-12-07 0:46 ` Bart Schaefer
0 siblings, 0 replies; only message in thread
From: Bart Schaefer @ 2022-12-07 0:46 UTC (permalink / raw)
To: Zsh hackers list
Redirecting to zsh-workers.
On Tue, Dec 6, 2022 at 3:54 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> On Tue, Dec 6, 2022, at 1:55 PM, Roman Perepelitsa wrote:
> > That said, it's totally possible to extend zsh with something like $[
> > ... ] which would work like $( ... ) but without forking. It would run
> > the commands in another thread within the same process.
>
> FWIW, ksh has a ${ list;} construct that avoids a subshell:
The "when followed by a space ${ starts a command, otherwise it's a
parameter reference" is a bit odd, but I guess not odder than some of
the things we do.
Based on some random poking at ksh93, this construct does two things:
1. Switches from fork-to-the-right (bash, older sh) behavior to
fork-to-the-left (zsh) behavior for pipes, so the rightmost part of a
pipeline may run in the current shell.
2. If the rightmost thing is a builtin, captures/substitutes its
output instead of printing it to stdout, otherwise acts exactly like
$(...)
Neither of those things actually requires a separate thread, though it
does require some engineering down in the guts of builtin commands to
replace simple stdio handling.
It'd be interesting to know how ksh93 handles the ^Z/fg issues with
left-forking that were recounted in recent -workers discussion.
^ permalink raw reply [flat|nested] only message in thread