Re: [PATCH?] Nofork and removing newlines

[Mikael Magnusson <mikachu@gmail.com>]

On 3/6/24, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Wed, Mar 6, 2024 at 9:57 AM Stephane Chazelas <stephane@chazelas.org>
> wrote:
>>
>> Sorry, I hadn't realised ${ cmd } also didn't do IFS-splitting,
>> so it is indeed departing a lot from command substitution and
>> assuming we don't care about keep compatibility with
>> ksh93/mksh/bash, I agree the proposed behaviour makes sense
>
> If SH_WORD_SPLIT is in fact set (as when emulating) then it is
> applied, so that's the other-shell-compatibility path.
>
>> Either way or always removing all newlines or always removing one
>> newline or removing one newline when not quoted are fine with me.
>
> Thanks.  Anyone else waiting to weigh in?

These are just some observations with no real conclusion probably.

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.
If you write a function that prints stuff, it is presumably pretty
easy to just make it not print the extra newlines in the first place.
If foo calls some external command that prints a newline then I
suppose 1) and 2) are not super relevant arguments.

"${ foo}" and ${ foo} having the same wordsplitting behavior but only
differing in stripping newlines feels a bit magical and weird. I would
feel surprised if it did wordsplitting without shwordsplit since it is
an extension of the ${} syntax which doesn't do it.

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

Is there some strong reason we could not allow ${(T) foo} btw? The
space is syntactically kind of similar to other stuff that does work
like ${(f)^param} and would save the extra ${}, but I didn't take a
look at the code yet.

-- 
Mikael Magnusson