Re: [PATCH?] Nofork and removing newlines

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Mar 6, 2024 at 2:22 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>
> 1) $(foo) will optimize away an extra fork if foo is an external command
> 2) ${ foo } will fork the same amount of times as 1) if foo is
> external and not at all if foo is a function.

You're almost quoting the FAQ entry. :-)

> "${ foo}" and ${ foo} having the same wordsplitting behavior but only
> differing in stripping newlines feels a bit magical and weird.

One question (and sort of the point) is whether anyone would really
notice.  If you put it in quotes you're expecting a literal result,
and if you (for example) assign it unquoted to a scalar you're
expecting it to "just work" the way assigning $(foo) would.  It's a
bit unusual but it seems to preserve the principle of least surprise,
and it uses the least amount of extra syntax.

On the other hand I'm not highly invested in this.  In the absence of
this (no)quoting behavior, I've found I nearly always want ${=${ foo
}} or ${(f)${ foo }}, each of which gives exactly the same result with
or without trimming.

> We could in theory add some new () flag, T for trim is free eg,
> ${(T)${ foo}} is somewhat more ergonomic than ${${ foo}%$'\n'}

I admittedly (still pre-patch) have used (f) for this when I know
there's only one line of output.  I'm just struggling to think of
where else I would use a (T).

Returning to this other bit ...

On Wed, Mar 6, 2024 at 2:42 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Mar 6, 2024 at 2:22 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> >
> > Is there some strong reason we could not allow ${(T) foo} btw?
>
> "{ " (curly bracket followed by space) is recognized like a syntax
> token.

Code-wise, a sequence starting with ${ (with or without the space) and
ending with } is lexed into a single STRING token.  (If it's inside
double quotes, the entire double-quoted thing is a STRING token, but
you can have nested quotes inside the dollar-brace inside the double
quotes, etc., so this has to work recursively, and so on.)  So the
lexer has to decide when it sees dollar-brace how to find the closing
brace.  Skipping over parameter flags before deciding to switch to
parsing something that looks like a function body might be possible,
but doesn't really fit into the structure of the lexer.  Deciding
based on the very next character (space or pipe for a command, or any
other for a parameter) makes it tractable.

The lexical problem aside, when you get to the point of performing the
substitution, even if the command interpretation were deferred until
after all the flags are collected, it would still have to function
much like ${(flags)"$(cmdsubst)"} would, so it's a lot easier if it's
already structured as a nested substitution.