Re: [PATCH?] Nofork and removing newlines

[Stephane Chazelas <stephane@chazelas.org>]

2024-03-05 14:48:00 -0800, Bart Schaefer:
> On Mon, Mar 4, 2024 at 10:56 PM Stephane Chazelas <stephane@chazelas.org> wrote:
> >
> > To me ${ cmd; } being the non-forking version of $(...) should
> > behave like $(...) in that regard.
> 
> That's the starting point of this discussion, yes.
> 
> > IMO, it's a bug in Bourne-like shells (and some others) that
> > $(...) removes *all* trailing newline characters, but removing
> > *one* is usually desired.
> 
> Ignoring the many-vs.-one issue, the pivotal word here is "usually".
> We can't change the behavior of $(...) but parameter expansions
> already behave differently with respect to SH_WORD_SPLIT so we have
> precedent for leeway on ${ ... }.  The suggested change would provide
> $(...)-like behavior for the usual case and a simple way to keep the
> newline(s) in the less-usual cases.

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 and
it's usefil to have a command substitution that doesn't trim all
newlines, so as you say I can do for my previous example:

basename="${${ basename -- "$file" }%$'\n'}"

To properly get the basename of $file with basename. (yes, I
know it's a bad example as we can also do basename=$file:t).

> > IIRC I already mentioned it here but maybe having a:
> >
> > ZSH_CMDSUBST_TRIM=<extendedglobpattern>
> 
> This is both IMO way too complicated and also misses the point that
> newline trimming or not ought to be easily switchable in the context
> of a single expansion, not globally.

The idea would be to allow users to fix command substitution
once and for all with ZSH_CMDSUBST_TRIM=$'\n'.

So things like:

basename=$(basename -- "$file")

become correct regardless of the value of $file without to have
to resort to ugly work arounds.

set -o fixcmdsubstrnewlinetrimming

would work as well be be less versatile.

(I agree that in any case that's rather tangential to the
question of what to do with ${ ... })

> My strong inclination is to either go with this patch or leave it as
> is.  The code change to implement this patch is literally two tokens.

Either way or always removing all newlines or always removing one
newline or removing one newline when not quoted are fine with me.

-- 
Stephane