From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Nofork ${{var}...} edge cases
Date: Wed, 27 Mar 2024 11:57:15 -0700 [thread overview]
Message-ID: <CAH+w=7YHZspc2JVBxkkYO69Cr9x__s-m4UQqRUfOetZYssUqnw@mail.gmail.com> (raw)
Just seeking opinions:
Should ${{} true} (empty variable name) result in "bad substitution"?
Otherwise it's all side-effects, because nothing will be substituted.
The prior ${|| true} form was a parse error.
Should ${{var}} be a "bad substitution", or print a warning about an
empty command? Otherwise it just substitutes $var.
What about ${{var};} or ${{var}{}} etc.?
Given:
% REPLY=123
Currently this works:
% print ${{REPLY} REPLY=abc}
abc
%
But the following does not substitute "b":
% print ${{REPLY[2]} REPLY=abc}
2
%
That's because REPLY is implicitly local to the substitution but
REPLY[2] becomes linked to the caller's $REPLY. (This is a problem
with |REPLY[2]| as well, not new with the braces.) With any other
name than REPLY, the subscript works as expected. How much effort is
it worth putting into fixing this? I would expect it more typical to
do:
% print ${${| REPLY=abc}[2]}
b
%
Or we could declare ${{REPLY}...} as NOT synonymous with ${|...} and
localize REPLY only in the latter of those. That might actually make
more sense.
In an earlier thread, Oliver asked:
> 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?
Among the reasons I listed for not doing this, I forgot to mention
that subscripts are allowed and you can't localize a subscripted
parameter.
I'd like to resolve these before I update the Doc.
next reply other threads:[~2024-03-27 18:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 18:57 Bart Schaefer [this message]
2024-03-27 22:22 ` Oliver Kiddle
2024-03-28 1:00 ` Bart Schaefer
2024-03-28 1:21 ` Bart Schaefer
2024-03-28 1:32 ` Bart Schaefer
2024-03-28 0:29 ` Mikael Magnusson
2024-03-28 1:12 ` Bart Schaefer
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=7YHZspc2JVBxkkYO69Cr9x__s-m4UQqRUfOetZYssUqnw@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).