{"thread":{"id":"32286","subject":"Weird problem with git-submodule.sh","startedAt":"2012-12-07T17:44:53Z","lastAt":"2012-12-12T23:12:58Z","messageCount":19,"participants":["Marc Branchaud","Junio C Hamano","marcnarc@xiplink.com","Andreas Schwab","Stefano Lattarini","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204576","messageId":"50C22B15.1030607@xiplink.com","threadId":"32286","inReplyTo":null,"subject":"Weird problem with git-submodule.sh","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-07T17:44:53Z","receivedAt":"2012-12-07T17:44:53Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Hi all,\n\nThis is with git 1.8.0.1 on all the machines involved.\n\nOne of our build machines is having trouble with \"git submodule\":\n\n\t$ git submodule init external/openssl\n\tNo submodule mapping found in .gitmodules for path ''\n\n(.gitmodules and other aspects of the repo are fine -- the submodules work\nperfectly on other machines.)\n\nThe problem seems to be in cmd_init() with the construct\n\n\tmodule_list \"$@\" |\n\twhile read mode sha1 stage sm_path\n\tdo\n\t\t...\n\nExplicitly setting IFS before the call to module_list makes it work:\n\n\tIFS=\" \"\n\tmodule_list \"$@\" |\n\twhile read mode sha1 stage sm_path\n\tdo\n\t\t...\n\nIf IFS is unset, the \"while read\" loop ends up with everything in the $mode\nvariable, and the other 3 variables are empty.\n\nIf I isolate module_list() and a simple \"while read\" loop into a standalone\nscript, like this:\n\n\tmodule_list()\n\t{\n\t\t...\n\t}\n\n\tmodule_list \"$@\" |\n\twhile read mode sha1 stage sm_path\n\tdo\n\t\techo - $mode - $sha1 - $stage - $sm_path -\n\tdone\n\nIt works -- each individual variable is set properly.\n\nIt seems that the problem only occurs inside git-submodule.sh.\n\nAny ideas?\n\n\t\tM.\n"},{"id":"204577","messageId":"7vvccdhhod.fsf@alter.siamese.dyndns.org","threadId":"32286","inReplyTo":"50C22B15.1030607@xiplink.com","subject":"Re: Weird problem with git-submodule.sh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-07T17:54:10Z","receivedAt":"2012-12-07T17:54:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> This is with git 1.8.0.1 on all the machines involved.\n>\n> One of our build machines is having trouble with \"git submodule\":\n> ...\n> Any ideas?\n\nHow and why is the IFS set differently only on one of your build\nmachines?\n"},{"id":"204580","messageId":"50C22F72.6010701@xiplink.com","threadId":"32286","inReplyTo":"7vvccdhhod.fsf@alter.siamese.dyndns.org","subject":"Re: Weird problem with git-submodule.sh","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-07T18:03:30Z","receivedAt":"2012-12-07T18:03:30Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-12-07 12:54 PM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> This is with git 1.8.0.1 on all the machines involved.\n>>\n>> One of our build machines is having trouble with \"git submodule\":\n>> ...\n>> Any ideas?\n> \n> How and why is the IFS set differently only on one of your build\n> machines?\n\nIt's not. On all machines:\n\t$ set | grep IFS\n\tIFS=$' \\t\\n'\n\nAs I said, if I isolate the module_list() function into another script it\nworks fine, with the exact same environment that breaks in git-submodule.sh.\n\nAlso, note that at the top of git-submodule there's\n\t. git-sh-setup\nwhich does\n\tunset IFS\n\n\t\tM.\n"},{"id":"204582","messageId":"7vwqwtfzis.fsf@alter.siamese.dyndns.org","threadId":"32286","inReplyTo":"50C22F72.6010701@xiplink.com","subject":"Re: Weird problem with git-submodule.sh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-07T19:11:39Z","receivedAt":"2012-12-07T19:11:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> On 12-12-07 12:54 PM, Junio C Hamano wrote:\n>> Marc Branchaud writes:\n>> \n>>> This is with git 1.8.0.1 on all the machines involved.\n>>>\n>>> One of our build machines is having trouble with \"git submodule\":\n>>> ...\n>>> Any ideas?\n>> \n>> How and why is the IFS set differently only on one of your build\n>> machines?\n>\n> It's not. On all machines:\n> \t$ set | grep IFS\n> \tIFS=$' \\t\\n'\n>\n> As I said, if I isolate the module_list() function into another script it\n> works fine, with the exact same environment that breaks in git-submodule.sh.\n>\n> Also, note that at the top of git-submodule there's\n> \t. git-sh-setup\n> which does\n> \tunset IFS\n\nYeah, now it makes sense why you wrote \"Weird\" on the subject line.\nWhat difference, if any, does the problematic box have compared to\nyour other healthy boxes? It uses a different /bin/sh?\n\nJust taking a shot in the dark...\n"},{"id":"204583","messageId":"50C24ED7.90000@xiplink.com","threadId":"32286","inReplyTo":"7vwqwtfzis.fsf@alter.siamese.dyndns.org","subject":"Re: Weird problem with git-submodule.sh","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-07T20:17:27Z","receivedAt":"2012-12-07T20:17:27Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-12-07 02:11 PM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> On 12-12-07 12:54 PM, Junio C Hamano wrote:\n>>> Marc Branchaud writes:\n>>>\n>>>> This is with git 1.8.0.1 on all the machines involved.\n>>>>\n>>>> One of our build machines is having trouble with \"git submodule\":\n>>>> ...\n>>>> Any ideas?\n>>>\n>>> How and why is the IFS set differently only on one of your build\n>>> machines?\n>>\n>> It's not. On all machines:\n>> \t$ set | grep IFS\n>> \tIFS=$' \\t\\n'\n>>\n>> As I said, if I isolate the module_list() function into another script it\n>> works fine, with the exact same environment that breaks in git-submodule.sh.\n>>\n>> Also, note that at the top of git-submodule there's\n>> \t. git-sh-setup\n>> which does\n>> \tunset IFS\n> \n> Yeah, now it makes sense why you wrote \"Weird\" on the subject line.\n> What difference, if any, does the problematic box have compared to\n> your other healthy boxes? It uses a different /bin/sh?\n> \n> Just taking a shot in the dark...\n\nBisected this down to exactly that \"unset IFS\" line in git-sh-setup.sh, from\nyour commit 785063e02bb249 (whaddya trying to do to me Junio?? :) ):\n\nAuthor: Junio C Hamano \nDate: Wed Aug 8 12:08:17 2012 -0700\n\n sh-setup: protect from exported IFS\n\n Many scripted Porcelains rely on being able to split words at the\n default $IFS characters, i.e. SP, HT and LF. If the user exports a\n non-default IFS to the environment, what they read from plumbing\n commands such as ls-files that use HT to delimit fields may not be\n split in the way we expect.\n\n Protect ourselves by resetting it, just like we do so against CDPATH\n exported to the environment.\n\n Noticed by Andrew Dranse .\n\n Signed-off-by: Junio C Hamano \n\nPerhaps IFS should be set to \" \\t\\n\" (which I believe is sh's default)\ninstead of just unsetting it altogether? (Note that in my testing I had to\nset IFS to a literal string.)\n\n\t\tM.\n"},{"id":"204584","messageId":"7vsj7hfw6q.fsf@alter.siamese.dyndns.org","threadId":"32286","inReplyTo":"50C24ED7.90000@xiplink.com","subject":"Re: Weird problem with git-submodule.sh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-07T20:23:41Z","receivedAt":"2012-12-07T20:23:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> sh-setup: protect from exported IFS\n>\n> Many scripted Porcelains rely on being able to split words at the\n> default $IFS characters, i.e. SP, HT and LF. If the user exports a\n> non-default IFS to the environment, what they read from plumbing\n> commands such as ls-files that use HT to delimit fields may not be\n> split in the way we expect.\n>\n> Protect ourselves by resetting it, just like we do so against CDPATH\n> exported to the environment.\n>\n> Noticed by Andrew Dranse .\n>\n> Signed-off-by: Junio C Hamano \n>\n> Perhaps IFS should be set to \" \\t\\n\" (which I believe is sh's default)\n> instead of just unsetting it altogether?\n\nPOSIX.1 says this:\n\n IFS - A string treated as a list of characters that is used for\n field splitting and to split lines into fields with the read\n command. If IFS is not set, it shall behave as normal for an\n unset variable, except that field splitting by the shell and\n line splitting by the read command shall be performed as if the\n value of IFS is ; see Field Splitting.\n\n Implementations may ignore the value of IFS in the environment, or\n the absence of IFS from the environment, at the time the shell is\n invoked, in which case the shell shall set IFS to \n when it is invoked.\n\nSo setting it to SP HT LF should not make a difference, or your\nshell is buggy.\n\nThis is exactly why I asked you about the /bin/sh on your\nproblematic box.\n"},{"id":"204586","messageId":"50C25539.9010206@xiplink.com","threadId":"32286","inReplyTo":"7vsj7hfw6q.fsf@alter.siamese.dyndns.org","subject":"Re: Weird problem with git-submodule.sh","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-07T20:44:41Z","receivedAt":"2012-12-07T20:44:41Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-12-07 03:23 PM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> sh-setup: protect from exported IFS\n>>\n>> Many scripted Porcelains rely on being able to split words at the\n>> default $IFS characters, i.e. SP, HT and LF. If the user exports a\n>> non-default IFS to the environment, what they read from plumbing\n>> commands such as ls-files that use HT to delimit fields may not be\n>> split in the way we expect.\n>>\n>> Protect ourselves by resetting it, just like we do so against CDPATH\n>> exported to the environment.\n>>\n>> Noticed by Andrew Dranse .\n>>\n>> Signed-off-by: Junio C Hamano \n>>\n>> Perhaps IFS should be set to \" \\t\\n\" (which I believe is sh's default)\n>> instead of just unsetting it altogether?\n> \n> POSIX.1 says this:\n> \n> IFS - A string treated as a list of characters that is used for\n> field splitting and to split lines into fields with the read\n> command. If IFS is not set, it shall behave as normal for an\n> unset variable, except that field splitting by the shell and\n> line splitting by the read command shall be performed as if the\n> value of IFS is ; see Field Splitting.\n> \n> Implementations may ignore the value of IFS in the environment, or\n> the absence of IFS from the environment, at the time the shell is\n> invoked, in which case the shell shall set IFS to \n> when it is invoked.\n> \n> So setting it to SP HT LF should not make a difference, or your\n> shell is buggy.\n> \n> This is exactly why I asked you about the /bin/sh on your\n> problematic box.\n\nFair 'nuf.\n\nIt's FreeBSD 7.2, which I know is an obsolete version but I'm not able to\nupgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.\n\nAnyway, given that there is at least one buggy version of sh, wouldn't it be\nbetter for git to explicitly set IFS?\n\n\t\tM.\n"},{"id":"204587","messageId":"50C25934.4080409@xiplink.com","threadId":"32286","inReplyTo":"7vsj7hfw6q.fsf@alter.siamese.dyndns.org","subject":"Re: Weird problem with git-submodule.sh","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-07T21:01:40Z","receivedAt":"2012-12-07T21:01:40Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-12-07 03:23 PM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> sh-setup: protect from exported IFS\n>>\n>> Many scripted Porcelains rely on being able to split words at the\n>> default $IFS characters, i.e. SP, HT and LF. If the user exports a\n>> non-default IFS to the environment, what they read from plumbing\n>> commands such as ls-files that use HT to delimit fields may not be\n>> split in the way we expect.\n>>\n>> Protect ourselves by resetting it, just like we do so against CDPATH\n>> exported to the environment.\n>>\n>> Noticed by Andrew Dranse .\n>>\n>> Signed-off-by: Junio C Hamano \n>>\n>> Perhaps IFS should be set to \" \\t\\n\" (which I believe is sh's default)\n>> instead of just unsetting it altogether?\n> \n> POSIX.1 says this:\n> \n> IFS - A string treated as a list of characters that is used for\n> field splitting and to split lines into fields with the read\n> command. If IFS is not set, it shall behave as normal for an\n> unset variable, except that field splitting by the shell and\n> line splitting by the read command shall be performed as if the\n> value of IFS is ; see Field Splitting.\n> \n> Implementations may ignore the value of IFS in the environment, or\n> the absence of IFS from the environment, at the time the shell is\n> invoked, in which case the shell shall set IFS to \n> when it is invoked.\n\nNot to defend anyone, but I can understand how an implementer might think\nthey're complying with the above while still deciding that an explicit \"unset\nIFS\" means IFS=''.\n\n\t\tM.\n"},{"id":"204588","messageId":"7vobi5fu3c.fsf@alter.siamese.dyndns.org","threadId":"32286","inReplyTo":"50C25539.9010206@xiplink.com","subject":"Re: Weird problem with git-submodule.sh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-07T21:08:55Z","receivedAt":"2012-12-07T21:08:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to\n> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.\n\nFinally. Yes, as you suspected, I am perfectly fine to explicitly\nset IFS to the default values.\n\nI wanted to have specific names to write in the commit log message,\nin-code comments and possibly release notes. That way, people can\ndecide if the issue affects them and they should upgrade once the\nfix is made.\n"},{"id":"204592","messageId":"1354918552-27150-1-git-send-email-marcnarc@xiplink.com","threadId":"32286","inReplyTo":"50C24ED7.90000@xiplink.com","subject":"[PATCH] sh-setup: Explicitly set IFS to its default, instead of unsetting it.","fromName":"","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-07T22:15:52Z","receivedAt":"2012-12-07T22:15:52Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"From: Marc Branchaud \n\nSome sh implementations interpret \"unset IFS\" to mean IFS=''. This was\nseen in FreeBSD 7.2's sh.\n\nWe need to make sure IFS has its default value: .\n\nSigned-off-by: Marc Branchaud \n---\n git-sh-setup.sh | 7 +++++--\n 1 file changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex ee0e0bc..56e6498 100644\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -12,8 +12,11 @@\n # But we protect ourselves from such a user mistake nevertheless.\n unset CDPATH\n \n-# Similarly for IFS\n-unset IFS\n+# Similarly for IFS, except that some sh implementations interpret \"unset IFS\"\n+# as IFS='', so we need to set IFS explicitly to its POSIX default using\n+# literal characters.\n+IFS=' \t\n+'\n \n git_broken_path_fix () {\n \tcase \":$PATH:\" in\n-- \n1.8.0.1\n"},{"id":"204593","messageId":"7va9tpfq46.fsf_-_@alter.siamese.dyndns.org","threadId":"32286","inReplyTo":"7vobi5fu3c.fsf@alter.siamese.dyndns.org","subject":"[PATCH] sh-setup: work around \"unset IFS\" bug in some shells","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-07T22:34:49Z","receivedAt":"2012-12-07T22:34:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"With an unset IFS, field splitting is supposed to act as if IFS is\nset to the usual SP HT LF, but Marc Branchaud reports that the shell\non FreeBSD 7.2 gets this wrong.\n\nIt is easy to set it to the default value manually, so let's do so.\n\nSigned-off-by: Junio C Hamano \n---\n git-sh-setup.sh | 7 +++++--\n 1 file changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex ee0e0bc..107c144 100644\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -12,8 +12,11 @@\n # But we protect ourselves from such a user mistake nevertheless.\n unset CDPATH\n \n-# Similarly for IFS\n-unset IFS\n+# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and\n+# do not equate an unset IFS with IFS with the default, so here is\n+# an explicit SP HT LF.\n+IFS=' \t\n+'\n \n git_broken_path_fix () {\n \tcase \":$PATH:\" in\n-- \n1.8.1.rc0.125.g5274144\n"},{"id":"204594","messageId":"50C26FA9.6060007@xiplink.com","threadId":"32286","inReplyTo":"7va9tpfq46.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] sh-setup: work around \"unset IFS\" bug in some shells","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-07T22:37:29Z","receivedAt":"2012-12-07T22:37:29Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"I like your patch's subject line better than mine.\n\n\t\tM.\n\n\nOn 12-12-07 05:34 PM, Junio C Hamano wrote:\n> With an unset IFS, field splitting is supposed to act as if IFS is\n> set to the usual SP HT LF, but Marc Branchaud reports that the shell\n> on FreeBSD 7.2 gets this wrong.\n> \n> It is easy to set it to the default value manually, so let's do so.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> git-sh-setup.sh | 7 +++++--\n> 1 file changed, 5 insertions(+), 2 deletions(-)\n> \n> diff --git a/git-sh-setup.sh b/git-sh-setup.sh\n> index ee0e0bc..107c144 100644\n> --- a/git-sh-setup.sh\n> +++ b/git-sh-setup.sh\n> @@ -12,8 +12,11 @@\n> # But we protect ourselves from such a user mistake nevertheless.\n> unset CDPATH\n> \n> -# Similarly for IFS\n> -unset IFS\n> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and\n> +# do not equate an unset IFS with IFS with the default, so here is\n> +# an explicit SP HT LF.\n> +IFS=' \t\n> +'\n> \n> git_broken_path_fix () {\n> \tcase \":$PATH:\" in\n> \n"},{"id":"204596","messageId":"m2fw3h8oja.fsf@igel.home","threadId":"32286","inReplyTo":"7va9tpfq46.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] sh-setup: work around \"unset IFS\" bug in some shells","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-12-07T22:50:49Z","receivedAt":"2012-12-07T22:50:49Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano writes:\n\n> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and\n> +# do not equate an unset IFS with IFS with the default, so here is\n> +# an explicit SP HT LF.\n> +IFS=' \t\n> +'\n\nTrailing whitespace can easily get lost, so it's probably better to\nstick a '' in here. The sequence is also easily being\nmangled to .\n\nIFS=' ''\t''\n'\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"204597","messageId":"7v624dfp1e.fsf@alter.siamese.dyndns.org","threadId":"32286","inReplyTo":"m2fw3h8oja.fsf@igel.home","subject":"Re: [PATCH] sh-setup: work around \"unset IFS\" bug in some shells","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-07T22:58:05Z","receivedAt":"2012-12-07T22:58:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> Junio C Hamano writes:\n>\n>> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and\n>> +# do not equate an unset IFS with IFS with the default, so here is\n>> +# an explicit SP HT LF.\n>> +IFS=' \t\n>> +'\n>\n> Trailing whitespace can easily get lost\n\nThe comment above the assingment spell the character names out for\nthat exact reason. Honestly, I think\n\n> IFS=' ''\t''\n> '\n\nis a lot harder to read. If we were writing in bash, we would\nprobably use $' \\t\\n' but because we aren't, the best you can do\nwith your approach is what you wrote, but it would make the reader\nwonder what these empty '' are there for and how many spaces are in\nbetween the '''' pair.\n\nIn other words, I agree with your concerns, but I do not think your\nrewrite helps very much.\n"},{"id":"204603","messageId":"m2vcccc2vd.fsf@linux-m68k.org","threadId":"32286","inReplyTo":"7v624dfp1e.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] sh-setup: work around \"unset IFS\" bug in some shells","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-12-08T09:25:10Z","receivedAt":"2012-12-08T09:25:10Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano writes:\n\n> Andreas Schwab writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and\n>>> +# do not equate an unset IFS with IFS with the default, so here is\n>>> +# an explicit SP HT LF.\n>>> +IFS=' \t\n>>> +'\n>>\n>> Trailing whitespace can easily get lost\n>\n> The comment above the assingment spell the character names out for\n> that exact reason. Honestly, I think\n\nThat won't help if you don't look for it. The loss can easily happen\nwhile you are in a different part of the file.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"204632","messageId":"50C4FD00.4010003@gmail.com","threadId":"32286","inReplyTo":"7vobi5fu3c.fsf@alter.siamese.dyndns.org","subject":"Re: Weird problem with git-submodule.sh","fromName":"Stefano Lattarini","fromEmail":"stefano.lattarini@gmail.com","sentAt":"2012-12-09T21:05:04Z","receivedAt":"2012-12-09T21:05:04Z","isPatch":false,"sender":{"key":"stefano.lattarini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1429199?v=4"},"body":"Hi Junio, Marc.\n\nOn 12/07/2012 10:08 PM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to\n>> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.\n> \n> Finally. Yes, as you suspected, I am perfectly fine to explicitly\n> set IFS to the default values.\n> \n> I wanted to have specific names to write in the commit log message,\n> in-code comments and possibly release notes. That way, people can\n> decide if the issue affects them and they should upgrade once the\n> fix is made.\n>\nThe Autoconf manual suggests against unsetting IFS instead of resetting\nit to the default sequence for yet another reason: if IFS is unset, code\nthat tries to save and restore its value will incorrectly reset it to an\nempty value, thus disabling field splitting:\n\n unset IFS\n # default separators used for field splitting\n # ...\n saved_IFS=$IFS\n IFS=:\n # code using the new IFS\n IFS=$saved_IFS\n # no field splitting performed from now on!\n\nNot sure how this is relevant for the Git codebase, but maybe it is\nsomething worth reporting in the commit message of a proposed patch.\n\nRegards,\n Stefano\n"},{"id":"204771","messageId":"CABURp0oc_g3T3n0A4on=n8443sTFR6SKf1xcgN2EAFcx9eU_Ng@mail.gmail.com","threadId":"32286","inReplyTo":"50C4FD00.4010003@gmail.com","subject":"Re: Weird problem with git-submodule.sh","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-12-12T19:10:44Z","receivedAt":"2012-12-12T19:10:44Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"Marc Branchaud writes:\n> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to\n> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.\n\nDash has been the default '/bin/sh' for Ubuntu for quite a long time\nnow[1] in spite of repeated reports of compatibility problems[2].\n\nPhil\n\n[1] https://wiki.ubuntu.com/DashAsBinSh\n[2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481\n"},{"id":"204777","messageId":"7vehiv3vjm.fsf@alter.siamese.dyndns.org","threadId":"32286","inReplyTo":"CABURp0oc_g3T3n0A4on=n8443sTFR6SKf1xcgN2EAFcx9eU_Ng@mail.gmail.com","subject":"Re: Weird problem with git-submodule.sh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T19:44:13Z","receivedAt":"2012-12-12T19:44:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord writes:\n\n> Marc Branchaud writes:\n>> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to\n>> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.\n>\n> Dash has been the default '/bin/sh' for Ubuntu for quite a long time\n> now[1] in spite of repeated reports of compatibility problems[2].\n\nWasn't the ancestry more like BSD ash (buggy) came before dash and\nMarc is running a BSD ash decendant that shared common ancestor\nwith, not a decendant of, dash?\n\nIn any case, I do not think that is relevant; does does not seem to\nhave this IFS bug.\n\n> [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481\n\nNone of the ones listed seems to me a bug. Rather, I see it as a\nsign that the reporter does not know POSIX shell well and only\nlearned his/her shell through bash.\n"},{"id":"204804","messageId":"CABURp0qCv9aaORMFnVTjaJ_QYD3h-=aOnu9BC8ZgUqRT3678hw@mail.gmail.com","threadId":"32286","inReplyTo":"7vehiv3vjm.fsf@alter.siamese.dyndns.org","subject":"Re: Weird problem with git-submodule.sh","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-12-12T23:12:58Z","receivedAt":"2012-12-12T23:12:58Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Wed, Dec 12, 2012 at 2:44 PM, Junio C Hamano wrote:\n> Phil Hord writes:\n>> [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481\n>\n> None of the ones listed seems to me a bug. Rather, I see it as a\n> sign that the reporter does not know POSIX shell well and only\n> learned his/her shell through bash.\n\nYou're probably right. I run into enough problems with 'dash' as\n/bin/sh that I always have to disable it early after a new install.\nIn particular, an third-party embedded linux kernel build script fails\nin cryptic ways with dash. But it is probably the third-party's poor\nunderstanding of POSIX shell which is to blame.\n\nI think git's 'make test' previously would also fail under dash, but\nit seems to be happy with it atm.\n\nPhil\n"}]}