Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH?] Nofork and removing newlines
- X-seq: zsh-workers 52690
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: [PATCH?] Nofork and removing newlines
- Date: Tue, 5 Mar 2024 14:48:00 -0800
- Archived-at: <https://zsh.org/workers/52690>
- In-reply-to: <20240305065606.ccr2ieheahslcpye@chazelas.org>
- List-id: <zsh-workers.zsh.org>
- References: <CAH+w=7aFJH-5GAu6puszGKvjqN-w0sPCi6v-vGPauDHVujDnag@mail.gmail.com> <20240305065606.ccr2ieheahslcpye@chazelas.org>
On Mon, Mar 4, 2024 at 10:56 PM Stephane Chazelas <stephane@xxxxxxxxxxxx> 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.
> 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.
So when I started the thread about ${ ... } the consensus was that it
would be OK to always keep the newlines and if you don't want them in
a particular case, you can write
${${ command }%$'\n'}.
Since then it's been pointed out that a lot of uses of $(...) that
would be replace-able with ${ ... } will break if the newlines are not
stripped, and it's a bit of a pain to have to remember that nesting
all the time. So the proposal made here has two goals:
1) Make it easy to replace many uses of $(...)
2) Make it easy to choose case-by-case whether to keep newlines
Thus
${ ... } strips newlines like $(...) for #1
"${ ... }" keeps them for handling #2
and if you want full SH_WORD_SPLIT behavior you can still write
${=${ ... }}
which is shorter and easier than the %$'\n' thing and strips newlines too.
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.
Thanks for the doc proofread.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author