From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: [PATCH?] Nofork and removing newlines
Date: Tue, 26 Mar 2024 18:16:26 -0700 [thread overview]
Message-ID: <CAH+w=7ar3v+QP6xt-5V7mCPjO0Y+RSKYE_v7BtFFatb1nV5BsQ@mail.gmail.com> (raw)
In-Reply-To: <20240315084226.rsgcm35fbqld3t2p@chazelas.org>
Delayed reply as I was traveling last week.
On Fri, Mar 15, 2024 at 1:42 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> What about, instead of adding ksh93's ${ cmd;} and mksh's
> ${|cmd} (in slightly diverging ways), we added just a |
> expansion flag
As mentioned in a previous context, the problem with this approach is
that the lexing/parsing of a parameter reference and the
lexing/parsing of what amounts to a function body are very different.
Upon encountering dollar-brace-pipe or dollar-brace-whitespace (or in
forthcoming proposed change, dollar-brace-brace), we can immediately
switch to expect a series of commands. This allows for one-character
lookahead, which works with hungetc(). If required first to consume
parameter flags or any string of multiple characters, the lexer can't
backtrack without some serious gyrations. Even if the backtracking
were worked out, the proposed flag now has semantics that the lexer
has to understand in order to proceed after the close-paren, whereas
current parameter flags are just swept up uninterpreted at lexing and
left to paramsubst() to decode.
On top of this the lexer has to maintain the PS2 context stack, which
was one of the most difficult bits of implementing the switch to/from
expecting commands vs. expecting (possibly nested) parameter
substitutions.
> Some advantages:
> - the flags can be cumulated as usual. So you can have ${(||.s[:])getconf PATH}
That would make this entirely impractical for lexing purposes.
> - there's no extra rule as to how the expansion works and how it
> can be combined with others as it's the same syntax as other
> parameter expansions
Except it's still not, because the syntax after the flags and up to
the matching close brace is nothing like identifiers / subscripts /
nested parameters.
> - as it's different syntax, it removes the potential surprises
> when ${ cmd;}, ${|cmd} behave differently than in
> ksh93/mksh/bash
Possibly, but since they'll work very similarly when in emulation
modes, I think this is minor.
> Or (as a completely different idea), an alternative to
> mksh's ${|cmd} and ${|var|cmd} could be written ${REPLY<cmd}
> ${var<cmd}.
I suspect that wouldn't interact as well with nested substitutions
(although I guess it wouldn't differ that much from ${REPLY=...} in
that respect), and it has the appearance of reading from a file. I
don't especially like ${|...} that way either as it looks more like
writing than reading, but we're not setting the precedent there.
Given druthers, I'd have done something with $(...) instead of ${...},
more like recognizing the "function" keyword so $(function { ... })
skips forking [ shorthand $(() { ... }) ] which could be done with
zero changes to the lexer/parser, but that already has conflicting
semantics with respect to [not] altering values in the current shell.
Patch to use ${{param} cmd} instead of ${|param| cmd} to follow in a bit.
next prev parent reply other threads:[~2024-03-27 1:17 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
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 [this message]
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=7ar3v+QP6xt-5V7mCPjO0Y+RSKYE_v7BtFFatb1nV5BsQ@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).