From: Oliver Kiddle <opk@zsh.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH?] Nofork and removing newlines
Date: Wed, 13 Mar 2024 00:19:33 +0100 [thread overview]
Message-ID: <25344-1710285573.990297@5-7t._0Mp.XRXG> (raw)
In-Reply-To: <CAH+w=7Zb_PWs-h2J9uOUMT6TQXnfPUAXyCWZUEcKyyDx0fDLhg@mail.gmail.com>
Bart Schaefer wrote:
> On Fri, Mar 8, 2024 at 2:15 PM Oliver Kiddle <opk@zsh.org> wrote:
> >
> > Why does it print command not found errors for things like ${|=|:},
> > ${|*|:} and ${|?|:}, I'd rather have $? than it globbing for a single
>
> Bart Schaefer wrote:
> > See above about the requirement for it to look like ${|ident|...}.
> > Since = * and ? are not identifiers, this is like writing { =|: } etc.
Considering this explanation, it is apparent that allowing |ident| is
not fully compatible with mksh where ${|ls| cat -} runs ls.
Not that I think that matters as such. In usage, it is probably wise to
make a convention of always having a space before the command starts.
And this leads on to the later question as we probably don't want to
expand considerably on what is valid between the vertical bars.
> This can be done with e.g.
>
> typeset -n bang=!
> ... ${|bang|...} ...
Yes that works. Is nice to see namerefs coming up in nifty solutions. I
hadn't checked the code for what supporting ? / ! would involve. If
trivial why not, but I well understand not wanting to do anything that
involves the lexer.
> However:
>
> Returning to the original context here, we were talking about how to
> make ${ ... } more newline-trimming-compatible with $(...) while still
> providing a way to specify that newlines not be trimmed, and using
> ${||...} for the latter came up.
>
> In thinking about ${|?|...} etc. I realized that there's no real
> reason a set of non-identifier characters couldn't be allowed to
> follow the first vertical bar. It'd have to be simpler than just
> tossing parameter expansion flags in there, but I could investigate
> whether we could do things like ${|=|...} is the same as ${=${ ... }},
> ${|~|...} is ${~${ ... }}, etc. That only saves 1 character, though,
> and I'm not sure it's clearer.
Would that potentially also extend to something like ${|=var| ... }
That might look like a default value assignment to someone used to a
language where vertical bars delimit closure parameters. Coming within
the vertical bars the character has a closer syntactic attachment to the
variable implying a semantic attachment. If it is hard to support
${= ... } then not doing it at all is probably better.
Given that the ${|var| ... } form appears to create a function-like
scope, should var perhaps be auto-declared local for that scope and the
local value be substituted?
> It does mean, though, that we could use something like ${|<|...} for
> non-trimming command substitution, instead of "empty" || meaning that.
> Just from a "clean look" standpoint, though, I still like the quoting
> approach better.
The quoting approach is clean and logical and is probably my preferred
option. I was initially bothered by the lack of consistency with $(...)
(where quoting prevents word splitting) but it can be useful if the lack
of fork is not the only thing which makes ${ ... } different and because
of the syntactic resemblance, consistency with ${var} is perhaps more
important - it does word splitting based on the shwordsplit option.
> Separately, it's definitely possible to make zsh-mode ${ ... } trim
> only one newline instead of all of them.
Only one is probably the most useful. I would mostly associate the fact
that $(...) strips multiple with the fact that it does word splitting
and so drops repeated newlines (empty words) also from the middle.
Admittedly "$(...)" preserves empty words in the middle but still drops
those at the end.
Oliver
next prev parent reply other threads:[~2024-03-12 23:20 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
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 [this message]
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=25344-1710285573.990297@5-7t._0Mp.XRXG \
--to=opk@zsh.org \
--cc=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).