From: Stephane Chazelas <stephane.chazelas@gmail.com>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH] Support the mksh's ${|func;} substitution
Date: Sat, 7 Sep 2019 21:19:54 +0100 [thread overview]
Message-ID: <20190907201954.dn2nve65wqk4muvc@chaz.gmail.com> (raw)
In-Reply-To: <CAKc7PVDC6NULei7FCKXvHu1YRzhmk9ZJK4BECRRxpWNQpHCw9w@mail.gmail.com>
2019-09-07 20:09:57 +0200, Sebastian Gniazdowski:
> On Sat, 7 Sep 2019 at 17:07, Stephane Chazelas
> <stephane.chazelas@gmail.com> wrote:
> > Note that mksh's operator can do ${|REPLY=value}, it's not
> > limited to functions.
>
> Ok, true, it can also run binary commands.
>
> > The ; is also not necessary
>
> I think that this is undocumented feature, as the docs say:
>
> "Another variant of substitution are the valsubs (value substitutions)
> ${|command;} which are also executed in the current environment, like
> funsubs, but share their I/O with the parent; instead, they evaluate
> to whatever the, initially empty, expression-local variable REPLY is
> set to within the commands."
[...]
Those operators are shaped after the ksh93 ${ cmdsubst;}
operator. ksh93 man page also mentions the ; there, but it's not
necessary either. In ksh93, ${(uname)} or ${ uname } (which for
those who wouldn't be familiar with those is the same as
$(cmdsubst) but without creating a subshell environment) also
work.
That is the { must be delimited from the following code, and }
delimited from the previous code.
The ${ cmd;} is reminiscent of { cmd;}, it makes sense to
document that form as it makes it more obvious what we're
talking about, but just like {(cmd)} also works ${(cmd)} works
as well (in ksh93, not in mksh). { cmd} doesn't work, but
${ cmd} does though (in mksh, not in ksh93 where you need
${ cmd }).
That discrepancy causes confusion:
$ ksh -c '{ echo }; }'
}
$ ksh -c 'echo ${ { echo }; }; }'
ksh: syntax error at line 1: `}' unexpected
(you can not longer use a bare "}" inside ${ ...; })
$ mksh -c 'echo ${ { echo }; echo x } y'
x y
$ ksh -c 'echo ${ { echo }; echo x } y'
ksh: syntax error at line 1: `{' unmatched
$ mksh -c '{ echo x }'
mksh: syntax error: unmatched '{'
It is quite messy.
In ksh93 ${ print foo;} is efficient because in that case
"print" doesn't write "foo\n", the "foo" makes up the result of
the expansion without any I/O being made. And it's also the case
in ${ myfunction; }. ksh93 only ever forks for executing
external commands or in pipelines. When inside a subshell, ksh93
adds the would-be-output data to the command-substitution-to-be
ksh93 was a complete rewrite (compared to ksh88). For mksh to be
able to do that, it would probably have had to be completely
rewritten as well.
Instead, in mksh, for ${ code; }, for the code not to run in a
subshell, the code's output is written to a temp file which is
read afterwards, which is less efficient as it involves I/O.
I suppose that's why the ${| cmd;} variant that uses the $REPLY
variable to transfer the data and avoids I/O was introduced
(you'd still get I/O through a pipe if you do ${|REPLY=$(print
test)}.
[...]
> > With those fixed, i.e. when it's really like mksh's ${|code},
> > I'd agree the feature could be useful, but I suspect that would
> > be harder to implement as it would mean changing the parsing.
>
> The parsing would have to be changed to prevent the "=" in function names?
[...]
No, I meant that you'd need the parser to handle that case of a
pseudo-command group (a {any shell code here} but with {|
instead of {)).
So you can do:
echo ${|
whatever $(...)
for i do
...
done}
Whether it would actually be difficult or not I can't comment,
I've not looked at the parser code.
Having an operator that *only* invokes a function to do an
expansion is less useful IMO. That just sound like a very
limited form of command substitution where you could have done a
more complete form by allowing any code instead of just one
function invocation without argument.
Note that mksh calls it "function substitution" not because you
can invoke a function within it but because the code in ${ code;
} is like in a function body, where it can have a local scope,
call return, but is a bit buggy when it comes to positional
parameters:
$ mksh -c 'echo "$@"; : "${ shift}"; echo "$@"' sh 1 2
1 2
sh 2
--
Stephane
next prev parent reply other threads:[~2019-09-07 20:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 0:52 Sebastian Gniazdowski
2019-09-06 0:54 ` Sebastian Gniazdowski
2019-09-06 23:16 ` Sebastian Gniazdowski
2019-09-07 12:16 ` Daniel Shahaf
2019-09-07 15:07 ` Stephane Chazelas
2019-09-07 18:09 ` Sebastian Gniazdowski
2019-09-07 20:19 ` Stephane Chazelas [this message]
2019-09-07 21:19 ` Sebastian Gniazdowski
2019-09-10 2:20 ` Sebastian Gniazdowski
2019-09-10 5:29 ` Bart Schaefer
2019-09-10 18:21 ` Sebastian Gniazdowski
2019-09-10 19:38 ` Bart Schaefer
2019-09-12 0:08 ` Sebastian Gniazdowski
2019-09-12 1:03 ` Bart Schaefer
2019-09-12 2:06 ` Sebastian Gniazdowski
2019-09-12 5:35 ` Bart Schaefer
2019-09-12 6:00 ` Sebastian Gniazdowski
2019-09-12 6:55 ` Bart Schaefer
2019-09-13 20:28 ` Sebastian Gniazdowski
2019-09-13 21:33 ` Bart Schaefer
2019-09-13 21:36 ` Bart Schaefer
2019-09-14 0:41 ` Sebastian Gniazdowski
2019-09-14 0:44 ` Sebastian Gniazdowski
2023-05-03 14:46 Sebastian Gniazdowski
2023-07-04 1:55 ` Bart Schaefer
2023-07-04 18:53 ` Lawrence Velázquez
2023-07-05 5:32 ` Bart Schaefer
2023-07-05 6:30 ` Bart Schaefer
2023-07-06 1:39 ` Bart Schaefer
2023-07-06 2:27 ` Mikael Magnusson
2023-07-06 4:00 ` Bart Schaefer
2023-07-18 3:14 ` 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=20190907201954.dn2nve65wqk4muvc@chaz.gmail.com \
--to=stephane.chazelas@gmail.com \
--cc=sgniazdowski@gmail.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).