Re: Incorrect alias expansion within command substitution

[Alex fxmbsw7 Ratchev]

On Thu, Feb 3, 2022, 20:02 Chet Ramey <chet.ramey@case.edu> wrote:

> 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.
>

alias 0='echo ' 1='$(( ' 2=')) ' data=2+3' '

thats why this doesnt work, or what

0 1 data 2
>


im your example above you misknow that aliases are expanded as only commands
you specify in $( '(' as the command
you maybe meant like i tried $((
cause ( is no math expression
no idea why mine failed, bash bug

>
>
> > 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/
>
>