Marc Branchaud [off-list ref] 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 [off-list ref].
Signed-off-by: Junio C Hamano [off-list ref]
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.
So setting it to SP HT LF should not make a difference, or your
shell is buggy.
This is exactly why I asked you about the /bin/sh on your
problematic box.
On 12-12-07 03:23 PM, Junio C Hamano wrote:
Marc Branchaud [off-list ref] writes:
quoted
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 [off-list ref].
Signed-off-by: Junio C Hamano [off-list ref]
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.
So setting it to SP HT LF should not make a difference, or your
shell is buggy.
This is exactly why I asked you about the /bin/sh on your
problematic box.
Fair 'nuf.
It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to
upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.
Anyway, given that there is at least one buggy version of sh, wouldn't it be
better for git to explicitly set IFS?
M.
On 12-12-07 03:23 PM, Junio C Hamano wrote:
Marc Branchaud [off-list ref] writes:
quoted
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 [off-list ref].
Signed-off-by: Junio C Hamano [off-list ref]
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.