[PATCH v2] config.sub: Work around command assignment bug in some shells.
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=bad echo >/dev/null; echo $x' good % jsh -c 'x=good; x=bad echo >/dev/null; echo $x' bad The config.sub script contains a few commands of the form: IFS=- read ... which triggers this bug, causing the IFS assignment to persist for the remainder of the script. This can cause misbehaviour in certain cases, for example: % jsh config.sub i386-linux-gnu config.sub: test: unknown operator gnu % jsh config.sub i386-gnu/linux sed: can't read s|gnu/linux|gnu|: No such file or directory Invalid configuration `i386-gnu/linux': OS `' not recognized * config.sub: Save and restore IFS explicitly to avoid shell bugs. --- config.sub | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) v2: Use 'echo' instead of ':' in the bug demonstration. diff --git a/config.sub b/config.sub index d80c5d7..5c36ad7 100755 --- a/config.sub +++ b/config.sub @@ -121,9 +121,10 @@ esac # Split fields of configuration type # shellcheck disable=SC2162 -IFS="-" read field1 field2 field3 field4 <
Re: [PATCH] config.sub: Work around command assignment bug in some shells.
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 :; echo $x' > bad > $ uname -a > SunOS sparcsol 5.10 Generic_150400-48 sun4v sparc SUNW,T5240 > > Debian 11 dash apparently does also, which seems surprising to me. This is my error, it is an incorrect demonstration of the problem because : is actually not a regular built-in, but rather it is a special built-in. POSIX specifies the dash behaviour, but not all shells implement this rule for special built-ins (e.g., bash does not unless run in POSIX compatibility mode). A better example using a regular built-in instead: % dash -c 'x=good; x=bad echo; echo $x' [blank line] good % jsh -c 'x=good; x=bad echo; echo $x' [blank line] bad I can spin a v2 patch with a new log message. Cheers, Nick
[PATCH] config.sub: Work around command assignment bug in some shells.
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=bad :; echo $x' good % jsh -c 'x=good; x=bad :; echo $x' bad The config.sub script contains a few commands of the form: IFS=- read ... which trigger this bug, causing the IFS assignment to persist for the remainder of the script. This can cause misbehaviour in certain cases, for example: % jsh config.sub i386-linux-gnu config.sub: test: unknown operator gnu % jsh config.sub i386-gnu/linux sed: can't read s|gnu/linux|gnu|: No such file or directory Invalid configuration `i386-gnu/linux': OS `' not recognized * config.sub: Save and restore IFS explicitly to avoid shell bugs. --- config.sub | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/config.sub b/config.sub index d80c5d7..5c36ad7 100755 --- a/config.sub +++ b/config.sub @@ -121,9 +121,10 @@ esac # Split fields of configuration type # shellcheck disable=SC2162 -IFS="-" read field1 field2 field3 field4 <
Re: config.sub/config.guess using nonportable $(...) substitutions
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 package using the latest bits, >> configuring with heirloom-sh fails: >> >> % CONFIG_SHELL=/bin/jsh jsh ./configure CONFIG_SHELL=/bin/jsh >> configure: error: cannot run /bin/jsh ./config.sub > > But why would you use CONFIG_SHELL= to specify a less capable shell? > It is there to specify a more capable shell in case it is not already > detected. It is simply a proxy to test Solaris /bin/sh behaviour using a modern GNU/Linux system. This is much easier and faster than actually testing on old Solaris systems and, more importantly, anyone can download and install this shell as it is free software and reasonably portable. Obviously I can successfully run my scripts on GNU/Linux using a modern shell such as GNU Bash. But that's not the point: Autoconf and friends are first and foremost portability tools. For me the goal is that this should be working anywhere that anyone might reasonably want to run it. But right now, it seems these portability tools are actually *causing* portability problems, rather than solving them. From my point of view this is a not so great situation. Cheers, Nick
config.sub/config.guess using nonportable $(...) substitutions
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 as, for example, Solaris 10 /bin/sh. This specific portability problem is discussed in the Autoconf manual for portable shell programming[1]. 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 package using the latest bits, configuring with heirloom-sh fails: % CONFIG_SHELL=/bin/jsh jsh ./configure CONFIG_SHELL=/bin/jsh configure: error: cannot run /bin/jsh ./config.sub % jsh config.sub x86_64-pc-linux-gnu config.sub: syntax error at line 53: `me=$' unexpected (The heirloom-sh is essentially Solaris /bin/sh but runs on GNU/Linux systems). What was the motivation for this change? Backquotes work fine and are more portable. Can we just revert it so the script works again with traditional shells? Surely these scripts should be maximally portable, I would think? [1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#index-_0024_0028commands_0029 Cheers, Nick
