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 <<EOF
+save_IFS=$IFS; IFS="-" read field1 field2 field3 field4 <<EOF
$1
EOF
+IFS=$save_IFS
# Separate into logical components for further validation
case $1 in
@@ -931,9 +932,10 @@ case $basic_machine in
*-*)
# shellcheck disable=SC2162
- IFS="-" read cpu vendor <<EOF
+ save_IFS=$IFS; IFS="-" read cpu vendor <<EOF
$basic_machine
EOF
+ IFS=$save_IFS
;;
# We use `pc' rather than `unknown'
# because (1) that's what they normally are, and
@@ -1313,9 +1315,10 @@ case $basic_os in
;;
*-*)
# shellcheck disable=SC2162
- IFS="-" read kernel os <<EOF
+ save_IFS=$IFS; IFS="-" read kernel os <<EOF
$basic_os
EOF
+ IFS=$save_IFS
;;
# Default OS when just kernel was specified
nto*)
--
2.31.1
