Date: Thu, 11 Apr 2024 15:54:21 +0100 From: "Kerin Millar" <k...@plushkava.net> Message-ID: <57e307d0-6a16-443b-82ce-adf540f96...@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