On 12-12-07 03:23 PM, Junio C Hamano wrote:
> Marc Branchaud <marcn...@xiplink.com> 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 <adra...@oanda.com>.
>> Signed-off-by: Junio C Hamano <gits...@pobox.com>
>> 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=''.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html