On 12-12-07 03:23 PM, Junio C Hamano wrote:
> Marc Branchaud <[email protected]> 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 <[email protected]>.
>>
>> Signed-off-by: Junio C Hamano <[email protected]>
>>
>> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
