Re: Incorrect alias expansion within command substitution

[Chet Ramey]

On 2/2/22 11:14 AM, L A Walsh wrote:
> On 2022/02/01 07:50, Chet Ramey wrote:
>>
>>
>> "Historically some shells used simple parenthesis counting to find the
>> terminating ')' and therefore did not account for aliases. However, such
>> shells never conformed to POSIX, which has always required recursive
>> parsing (see XCU 2.3 item 5)."
>>   
> ----
>    It doesn't require recursive parsing if the aliases declared
> in the parent shell are expanded in the child shell -- i.e. if
> bash followed the posix requirement that alias expansion default to
> on, then the aliases in the BASH_ALIASES data structure would
> automatically be imported into the child shell and expanded and this
> type of complicated parsing problem wouldn't occur. 

This makes it seem like you haven't followed the discussion so far.

Your paragraph describes bash's historical behavior. That is not POSIX
conformant, and never has been. It is, however, entrenched, and backwards
compatibility means we have to figure out a way to accommodate it.

POSIX requires recursive parsing because it's required to find the correct
closing right paren. Bash's ad-hoc lexical scanning got pretty good, but it
was never a complete substitute for a true parse, and alias expansion was
only a part of that.

Not only can alias expansions affect parsing, they can affect which right
paren is the correct one.

POSIX has always said that "Any valid shell script can be used for
command" in $( command ).

Consider the following script:

set -o posix

alias switch=case

switch foo in foo) echo ok 1;; esac
echo $( switch foo in foo) echo ok 2;; esac )

POSIX requires this to output

ok 1
ok 2

No version of bash before bash-5.2-alpha handled this correctly. The
discussion we're having right now, the result of Martijn's bug report, is
how to handle the POSIX-required behavior and the historical bash
behavior, when you clearly can't have both. (The bug Martijn reported was
the result of trying to have both.)

> It seems
> like the reason this error is occurring, is because someone is trying to
> work around bash's incompatibility with the posix standard by not starting
> with aliases turned on by default.

No. This is not at all correct. In fact, it completely misses the issue.
In your rush to criticize bash's "non-conformance," you haven't stopped to
consider the problems.

I recommend you read

https://lists.gnu.org/archive/html/bug-bash/2022-02/msg00000.html

and re-read the message you quoted above.

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