summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: fe6c64a)
raw | patch | inline | side by side (parent: fe6c64a)
author | Michael J Gruber <git@drmicha.warpmail.net> | |
Sat, 3 Mar 2012 00:37:35 +0000 (19:37 -0500) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Sat, 3 Mar 2012 07:06:08 +0000 (23:06 -0800) |
The construct 'while IFS== read' makes dash 0.5.6 execute
read without changing IFS, which results in test breakages
all over the place in t0300. Neither dash 0.5.5.1 and older
nor dash 0.5.7 and newer are affected: The problem was
introduded resp. fixed by the commits
55c46b7 ([BUILTIN] Honor tab as IFS whitespace when
splitting fields in readcmd, 2009-08-11)
1d806ac ([VAR] Do not poplocalvars prematurely on regular
utilities, 2010-05-27)
in http://git.kernel.org/?p=utils/dash/dash.git
Putting 'IFS==' before that line makes all versions of dash
work.
This looks like a dash bug, not a misinterpretation of the
standard. However, it's worth working around for two
reasons. One, this version of dash was released in Fedora
14-16, so the bug is found in the wild. And two, at least
one other shell, Solaris /bin/sh, choked on this by
persisting IFS after the read invocation. That is not a
shell we usually care about, and I think this use of IFS is
acceptable by POSIX (which allows other behavior near
"special builtins", but "read" is not one of those). But it
seems that this may be a subtle, not-well-tested case for
some shells. Given that the workaround is so simple, it's
worth just being defensive.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read without changing IFS, which results in test breakages
all over the place in t0300. Neither dash 0.5.5.1 and older
nor dash 0.5.7 and newer are affected: The problem was
introduded resp. fixed by the commits
55c46b7 ([BUILTIN] Honor tab as IFS whitespace when
splitting fields in readcmd, 2009-08-11)
1d806ac ([VAR] Do not poplocalvars prematurely on regular
utilities, 2010-05-27)
in http://git.kernel.org/?p=utils/dash/dash.git
Putting 'IFS==' before that line makes all versions of dash
work.
This looks like a dash bug, not a misinterpretation of the
standard. However, it's worth working around for two
reasons. One, this version of dash was released in Fedora
14-16, so the bug is found in the wild. And two, at least
one other shell, Solaris /bin/sh, choked on this by
persisting IFS after the read invocation. That is not a
shell we usually care about, and I think this use of IFS is
acceptable by POSIX (which allows other behavior near
"special builtins", but "read" is not one of those). But it
seems that this may be a subtle, not-well-tested case for
some shells. Given that the workaround is so simple, it's
worth just being defensive.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t0300-credentials.sh | patch | blob | history |
diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
index 885af8fb62a32be5d52cdf78f40b679c55cb385d..c1c8108148351ab3ec3db3f2615ff88f29d38974 100755 (executable)
--- a/t/t0300-credentials.sh
+++ b/t/t0300-credentials.sh
cat >dump <<-\EOF &&
whoami=`echo $0 | sed s/.*git-credential-//`
echo >&2 "$whoami: $*"
- while IFS== read key value; do
+ OIFS=$IFS
+ IFS==
+ while read key value; do
echo >&2 "$whoami: $key=$value"
eval "$key=$value"
done
+ IFS=$OIFS
EOF
cat >git-credential-useless <<-\EOF &&