When combining variable assignments with a shell command, some older
shells (notably heirloom-sh and presumably also Solaris 10 /bin/sh)
have a bug which causes the assignment to alter the current execution
environment whenever the command is a shell built-in. For example:
% dash -c 'x=good; x=
On 13/08/2021, Karl Berry wrote:
> When combining variable assignments with a shell command, some older
> shells (notably heirloom-sh and presumably also Solaris 10 /bin/sh)
>
> Just to confirm: Solaris 10 /bin/sh does indeed also have this bug.
>
> sparcsol$ /bin/sh -c 'x=good; x=bad :; e
When combining variable assignments with a shell command, some older
shells (notably heirloom-sh and presumably also Solaris 10 /bin/sh)
have a bug which causes the assignment to alter the current execution
environment whenever the command is a shell built-in. For example:
% bash -c 'x=good; x=
On 2021-03-08, Tim Rice wrote:
> On Mon, 8 Mar 2021, Nick Bowler wrote:
[...]
>> These scripts using $(...) are incorporated into the recently-released
>> Automake 1.16.3, which means they get copied into packages bootstrapped
>> with this version. So now, if I create a pac
Hi,
I noticed that config.sub (and config.guess) scripts were very recently
changed to use the POSIX $(...) form for command substitutions.
This change is, I fear, ill-advised. The POSIX construction is
widely understood to be nonportable as it is not supported by
traditional Bourne shells such
