On 12-12-07 02:11 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:
>
>> On 12-12-07 12:54 PM, Junio C Hamano wrote:
>>> Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:
>>>
>>>> This is with git 1.8.0.1 on all the machines involved.
>>>>
>>>> One of our build machines is having trouble with "git submodule":
>>>> ...
>>>> Any ideas?
>>>
>>> How and why is the IFS set differently only on one of your build
>>> machines?
>>
>> It's not. On all machines:
>> $ set | grep IFS
>> IFS=$' \t\n'
>>
>> As I said, if I isolate the module_list() function into another script it
>> works fine, with the exact same environment that breaks in git-submodule.sh.
>>
>> Also, note that at the top of git-submodule there's
>> . git-sh-setup
>> which does
>> unset IFS
>
> Yeah, now it makes sense why you wrote "Weird" on the subject line.
> What difference, if any, does the problematic box have compared to
> your other healthy boxes? It uses a different /bin/sh?
>
> Just taking a shot in the dark...
Bisected this down to exactly that "unset IFS" line in git-sh-setup.sh, from
your commit 785063e02bb249 (whaddya trying to do to me Junio?? :) ):
Author: Junio C Hamano <gitster@xxxxxxxxx>
Date: Wed Aug 8 12:08:17 2012 -0700
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? (Note that in my testing I had to
set IFS to a literal <space><tab><newline> string.)
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