zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH?] Nofork and removing newlines
Date: Tue, 5 Mar 2024 14:48:00 -0800	[thread overview]
Message-ID: <CAH+w=7Yb6_eULBq6Ez6pEhtUXOqErr+aDL2BDi7zyxr8QpsTiw@mail.gmail.com> (raw)
In-Reply-To: <20240305065606.ccr2ieheahslcpye@chazelas.org>

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.

> 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.


  reply	other threads:[~2024-03-05 22:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05  5:52 Bart Schaefer
2024-03-05  6:56 ` Stephane Chazelas
2024-03-05 22:48   ` Bart Schaefer [this message]
2024-03-06 17:57     ` Stephane Chazelas
2024-03-06 19:45       ` Bart Schaefer
2024-03-06 22:22         ` Mikael Magnusson
2024-03-06 22:42           ` Bart Schaefer
2024-03-07  4:53           ` Bart Schaefer
2024-03-07  7:02             ` Lawrence Velázquez
2024-03-07  8:09               ` ${<file} (Was: [PATCH?] Nofork and removing newlines) Stephane Chazelas
2024-03-08  1:29               ` [PATCH?] Nofork and removing newlines Bart Schaefer
2024-03-08 22:15                 ` Oliver Kiddle
2024-03-08 23:28                   ` Bart Schaefer
2024-03-09 20:43                     ` Oliver Kiddle
2024-03-10  6:11                       ` Bart Schaefer
2024-03-12 17:54                         ` Bart Schaefer
2024-03-12 23:19                           ` Oliver Kiddle
2024-03-13  4:13                             ` Bart Schaefer
2024-03-14 22:15                               ` Oliver Kiddle
2024-03-15  8:42                                 ` Stephane Chazelas
2024-03-27  1:16                                   ` Bart Schaefer
2024-03-27  7:05                                 ` Bart Schaefer
2024-03-07  7:10             ` Stephane Chazelas
2024-03-08  0:37               ` Bart Schaefer
2024-03-07  6:52           ` Lawrence Velázquez
2024-03-07  8:26             ` Mikael Magnusson
2024-03-07 19:02               ` Bart Schaefer
2024-04-02  6:45                 ` Lawrence Velázquez
2024-03-06 19:43     ` Stephane Chazelas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7Yb6_eULBq6Ez6pEhtUXOqErr+aDL2BDi7zyxr8QpsTiw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).