Re: Incorrect alias expansion within command substitution

[Chet Ramey]

On 2/2/22 1:30 PM, Robert Elz wrote:
>      Date:        Wed, 2 Feb 2022 11:38:30 -0500
>      From:        Chet Ramey <chet.ramey@case.edu>
>      Message-ID:  <7c422cbb-bba8-0a57-a565-eeb115120e45@case.edu>
>
>
>    | > How accurately can you reconstitute?   That is, can you maintain the
>    | > difference between $(a b) and $( a b ) for example ?   How about $(a  b) 
> ?
>    |
>    | Does it make a semantic difference?
>
> No, but that's not the point.

My argument is like yours -- is there a return on the investment of effort
to make it worth doing, if the current state preserves semantics?

It's clear that POSIX requires recursive parsing during which aliases are
expanded. Changing the code to do that is worth the effort: it's my effort
and I get to make that judgement.

It's less clear that POSIX requires the exact original text, and it's just
as clear that, let's say, implementations differ in this area.


>    | The only thing I can think of that
>    | might mess it up is when you have something like
>    |
>    | alias l='(' r=')'
>    | echo $(l 4+4 r)
>    |
>    | and you intend, for whatever perverse reason, to have this parsed as an
>    | arithmetic expansion. I'm not sure that's worth supporting.
>
> Supporting that would be wrong.  

And that's why bash doesn't do it.


> The case I had in question with the question about $( a b ) was this
> one...
>
>         cat <<$( a b )
>         hello
>         $( a b )
>
> which works in bash 5.1.16, but doesn't in 5.2-(December 16).  In the
> latter the end line needs to be $(a b).   The spaces are lost - reconstituting
> really doesn't work for this purpose.   (nb: no aliases involved anywhere
> here).

Refer to my ROI comment above.

> For what it is worth, ksh93 (the version I have anyway) doesn't even
> get started...
>
> ksh93 $ cat <<$( a b )
> /usr/pkg/bin/ksh93: syntax error at line 1: `<<b' here-document not contained 
> within command substitution
>
> And I hate to even imagine what state it got itself into to produce that
> diagnostic.

The only person reading this with a chance to know that answer is Martijn.


>    | You need to be able to reconstruct the text of arbitrary commands for
>    | `set -x'. It's a very short step from that to rebuilding a command
>    | substitution.
>
> There are some things that -x typically does not show anything like
> as input (in bash, try a case statement for example).   What appears
> is fine for -x output, but not even close for reconstitution.

OK. You need to be able to reconsistute text for `type' output. That
includes everything, including redirections, because you need it to
accurately reproduce shell functions.

> This one works in released bash, but not in 5.2-xxx (and no white space
> tricks with this one to mess things up --- and I also did not try to guess
> what the end delimiter might actually work, if anything):
>
> cat <<$(case $x in a) echo found A;; b) echo found B;& *) echo found $x ;; esac)
> hello
> $(case $x in a) echo found A;; b) echo found B;& *) echo found $x ;; esac)

These examples are getting more and more hyperbolic. I'm comfortable with
not supporting this use case.


> cat <<$(cat</dev/null)
> hello
> $(cat</dev/null)

It's not because the reconstituted text doesn't include redirections; the
error message tells you that. And, in fact, this works:

cat <<$(cat</dev/null)
hello
$(cat < /dev/null)

though that's neither here nor there.

> If you abandoned reconstituting, and simply saved the string, however
> difficult that might be none of these issues would arise.
>
> It must be possible, the lexer is reading chars from somewhere, all it
> needs to happen is to be told when to start saving, and when to stop).

Of course it's possible. Is it worth the implementation effort?

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/