Re: Weird problem with git-submodule.sh
Marc Branchaud marcn...@xiplink.com writes: 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. Dash has been the default '/bin/sh' for Ubuntu for quite a long time now[1] in spite of repeated reports of compatibility problems[2]. Phil [1] https://wiki.ubuntu.com/DashAsBinSh [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481 -- 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
Re: Weird problem with git-submodule.sh
Phil Hord phil.h...@gmail.com writes: Marc Branchaud marcn...@xiplink.com writes: 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. Dash has been the default '/bin/sh' for Ubuntu for quite a long time now[1] in spite of repeated reports of compatibility problems[2]. Wasn't the ancestry more like BSD ash (buggy) came before dash and Marc is running a BSD ash decendant that shared common ancestor with, not a decendant of, dash? In any case, I do not think that is relevant; does does not seem to have this IFS bug. [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481 None of the ones listed seems to me a bug. Rather, I see it as a sign that the reporter does not know POSIX shell well and only learned his/her shell through bash. -- 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
Re: Weird problem with git-submodule.sh
On Wed, Dec 12, 2012 at 2:44 PM, Junio C Hamano gits...@pobox.com wrote: Phil Hord phil.h...@gmail.com writes: [2] https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481 None of the ones listed seems to me a bug. Rather, I see it as a sign that the reporter does not know POSIX shell well and only learned his/her shell through bash. You're probably right. I run into enough problems with 'dash' as /bin/sh that I always have to disable it early after a new install. In particular, an third-party embedded linux kernel build script fails in cryptic ways with dash. But it is probably the third-party's poor understanding of POSIX shell which is to blame. I think git's 'make test' previously would also fail under dash, but it seems to be happy with it atm. Phil -- 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
Re: Weird problem with git-submodule.sh
Hi Junio, Marc. On 12/07/2012 10:08 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: 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. Finally. Yes, as you suspected, I am perfectly fine to explicitly set IFS to the default values. I wanted to have specific names to write in the commit log message, in-code comments and possibly release notes. That way, people can decide if the issue affects them and they should upgrade once the fix is made. The Autoconf manual suggests against unsetting IFS instead of resetting it to the default sequence for yet another reason: if IFS is unset, code that tries to save and restore its value will incorrectly reset it to an empty value, thus disabling field splitting: unset IFS # default separators used for field splitting # ... saved_IFS=$IFS IFS=: # code using the new IFS IFS=$saved_IFS # no field splitting performed from now on! Not sure how this is relevant for the Git codebase, but maybe it is something worth reporting in the commit message of a proposed patch. Regards, Stefano -- 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
Re: Weird problem with git-submodule.sh
Marc Branchaud marcn...@xiplink.com 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? -- 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
Re: Weird problem with git-submodule.sh
On 12-12-07 12:54 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com 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 M. -- 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
Re: Weird problem with git-submodule.sh
Marc Branchaud marcn...@xiplink.com writes: On 12-12-07 12:54 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com 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... -- 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
Re: Weird problem with git-submodule.sh
On 12-12-07 02:11 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: On 12-12-07 12:54 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com 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 gits...@pobox.com 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 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? (Note that in my testing I had to set IFS to a literal spacetabnewline string.) M. -- 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
Re: Weird problem with git-submodule.sh
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. 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. -- 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
Re: Weird problem with git-submodule.sh
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. 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. -- 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
Re: Weird problem with git-submodule.sh
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=''. M. -- 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
