On 12-12-07 03:23 PM, Junio C Hamano wrote: > Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > >> sh-setup: protect from exported IFS >> >> Many scripted Porcelains rely on being able to split words at the >> default $IFS characters, i.e. SP, HT and LF. If the user exports a >> non-default IFS to the environment, what they read from plumbing >> commands such as ls-files that use HT to delimit fields may not be >> split in the way we expect. >> >> Protect ourselves by resetting it, just like we do so against CDPATH >> exported to the environment. >> >> Noticed by Andrew Dranse <adranse@xxxxxxxxx>. >> >> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> >> >> Perhaps IFS should be set to " \t\n" (which I believe is sh's default) >> instead of just unsetting it altogether? > > POSIX.1 says this: > > IFS - A string treated as a list of characters that is used for > field splitting and to split lines into fields with the read > command. If IFS is not set, it shall behave as normal for an > unset variable, except that field splitting by the shell and > line splitting by the read command shall be performed as if the > value of IFS is <space> <tab> <newline>; see Field Splitting. > > Implementations may ignore the value of IFS in the environment, or > the absence of IFS from the environment, at the time the shell is > invoked, in which case the shell shall set IFS to <space> <tab> > <newline> when it is invoked. Not to defend anyone, but I can understand how an implementer might think they're complying with the above while still deciding that an explicit "unset IFS" means IFS=''. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html