Re: [PATCH] Support the mksh's ${|func;} substitution

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

2019-09-07 20:09:57 +0200, Sebastian Gniazdowski:
> On Sat, 7 Sep 2019 at 17:07, Stephane Chazelas
> <stephane.chazelas@xxxxxxxxx> 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