summaryrefslogtreecommitdiff
path: root/t/t1013/objects/e6
diff options
context:
space:
mode:
authorLibravatar Michael J Gruber <git@drmicha.warpmail.net>2012-03-02 19:37:35 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-03-02 23:06:08 -0800
commit78ed1d2d63390694cb6c451896086fb7338f75b6 (patch)
treeef840eae16917f4d3cdb90bc7a2b7081a455075e /t/t1013/objects/e6
parentt5512 (ls-remote): modernize style (diff)
downloadtgif-78ed1d2d63390694cb6c451896086fb7338f75b6.tar.xz
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 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>
Diffstat (limited to 't/t1013/objects/e6')
0 files changed, 0 insertions, 0 deletions