Re: Exporting functions does not expand aliases in subshells

[Robert Elz]

    Date:        Thu, 11 Apr 2024 15:54:21 +0100
    From:        "Kerin Millar" <kfm@plushkava.net>
    Message-ID:  <57e307d0-6a16-443b-82ce-adf540f9645c@app.fastmail.com>

  | The behaviour of dash seems more logical to me,
  | though I am uncertain as to which shell is in the right.

In as much as how aliases work, who cares?   They're insane anyway.

As for how/when the command substitutions are parsed, both are OK.

In some sense, according to POSIX, the bash way is perhaps slightly
more in accordance with how they assume expansions happen (which is
what a command substitution is) - but aside from aliases, it makes
no difference at all which way is used - the dash (ash derived shells
in general) way means parsing the command substitution only once
(which means guaranteed consistent results), whereas bash needs to
parse it perhaps multiple times - once where its only purpose is
to locate the end of the cmdsub, and then once every time the
command containing the cmdsub is executed (of course, the parse
time is likely dwarfed by execution time of the cmdsub, but wasting
time parsing things over and over again, where apart from possible
bizarre alias effects, the results will be the same every time, seems
wasteful to me).

For how aliases can mess things up, with the bash way of parsing
command substitutions, if we do:

        foo() { echo hello; X=$(echo goodbye); echo "$X"; }

and just run foo then we get "hello", "goodbye" (on successive lines).

If we then do

alias echo='echo say'

and run foo again (without redefining it) then we get "hello" "say goodbye"

as the first "echo" was already parsed, the (later) alias can't
affect that one, but the one in the command substitution hasn't
been (properly) parsed yet, so the alias affects that.

In the ash shell style, once a function is defined, it is defined,
and adding or changing aliases (other than for the name of the
function) later will not effect anything except an included "eval"
(or '.' command) (including a trap execution, which is just an eval
at a less predictable time).

kre