Michael J Gruber  committed 78ed1d2

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

  • Participants
  • Parent commits fe6c64a

Comments (0)

Files changed (1)

File t/

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