Re: [PATCH?] Nofork and removing newlines

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Delayed reply as I was traveling last week.

On Fri, Mar 15, 2024 at 1:42 AM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
>
> What about, instead of adding ksh93's ${ cmd;} and mksh's
> ${|cmd} (in slightly diverging ways), we added just a |
> expansion flag

As mentioned in a previous context, the problem with this approach is
that the lexing/parsing of a parameter reference and the
lexing/parsing of what amounts to a function body are very different.
Upon encountering dollar-brace-pipe or dollar-brace-whitespace (or in
forthcoming proposed change, dollar-brace-brace), we can immediately
switch to expect a series of commands.  This allows for one-character
lookahead, which works with hungetc(). If required first to consume
parameter flags or any string of multiple characters, the lexer can't
backtrack without some serious gyrations.  Even if the backtracking
were worked out, the proposed flag now has semantics that the lexer
has to understand in order to proceed after the close-paren, whereas
current parameter flags are just swept up uninterpreted at lexing and
left to paramsubst() to decode.

On top of this the lexer has to maintain the PS2 context stack, which
was one of the most difficult bits of implementing the switch to/from
expecting commands vs. expecting (possibly nested) parameter
substitutions.

> Some advantages:
> - the flags can be cumulated as usual. So you can have ${(||.s[:])getconf PATH}

That would make this entirely impractical for lexing purposes.

> - there's no extra rule as to how the expansion works and how it
>   can be combined with others as it's the same syntax as other
>   parameter expansions

Except it's still not, because the syntax after the flags and up to
the matching close brace is nothing like identifiers / subscripts /
nested parameters.

> - as it's different syntax, it removes the potential surprises
>   when ${ cmd;}, ${|cmd} behave differently than in
>   ksh93/mksh/bash

Possibly, but since they'll work very similarly when in emulation
modes, I think this is minor.

> Or (as a completely different idea), an alternative to
> mksh's ${|cmd} and ${|var|cmd} could be written ${REPLY<cmd}
> ${var<cmd}.

I suspect that wouldn't interact as well with nested substitutions
(although I guess it wouldn't differ that much from ${REPLY=...} in
that respect), and it has the appearance of reading from a file.  I
don't especially like ${|...} that way either as it looks more like
writing than reading, but we're not setting the precedent there.

Given druthers, I'd have done something with $(...) instead of ${...},
 more like recognizing the "function" keyword so $(function { ... })
skips forking [ shorthand $(() { ... }) ] which could be done with
zero changes to the lexer/parser, but that already has conflicting
semantics with respect to [not] altering values in the current shell.

Patch to use ${{param} cmd} instead of ${|param| cmd} to follow in a bit.