bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incorrect alias expansion within command substitution


From: Alex fxmbsw7 Ratchev
Subject: Re: Incorrect alias expansion within command substitution
Date: Thu, 3 Feb 2022 22:15:59 +0100

On Thu, Feb 3, 2022, 22:14 Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> wrote:

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

the eval variant is worse

0 1 data 2
bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]