Browse files

t0300: work around bug in dash 0.5.6

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 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)


Putting 'IFS==' before that line makes all versions of dash

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 <>
Signed-off-by: Jeff King <>
Signed-off-by: Junio C Hamano <>
  • Loading branch information...
mjg authored and gitster committed Mar 3, 2012
1 parent fe6c64a commit 78ed1d2d63390694cb6c451896086fb7338f75b6
Showing with 4 additions and 1 deletion.
  1. +4 −1 t/
@@ -8,10 +8,13 @@ test_expect_success 'setup helper scripts' '
cat >dump <<-\EOF &&
whoami=`echo $0 | sed s/.*git-credential-//`
echo >&2 "$whoami: $*"
- while IFS== read key value; do
+ IFS==
+ while read key value; do
echo >&2 "$whoami: $key=$value"
eval "$key=$value"
cat >git-credential-useless <<-\EOF &&

0 comments on commit 78ed1d2

Please sign in to comment.