* Weird problem with git-submodule.sh
@ 2012-12-07 17:44 Marc Branchaud
2012-12-07 17:54 ` Junio C Hamano
0 siblings, 1 reply; 19+ messages in thread
From: Marc Branchaud @ 2012-12-07 17:44 UTC (permalink / raw
To: Git Mailing List
Hi all,
This is with git 1.8.0.1 on all the machines involved.
One of our build machines is having trouble with "git submodule":
$ git submodule init external/openssl
No submodule mapping found in .gitmodules for path ''
(.gitmodules and other aspects of the repo are fine -- the submodules work
perfectly on other machines.)
The problem seems to be in cmd_init() with the construct
module_list "$@" |
while read mode sha1 stage sm_path
do
...
Explicitly setting IFS before the call to module_list makes it work:
IFS=" "
module_list "$@" |
while read mode sha1 stage sm_path
do
...
If IFS is unset, the "while read" loop ends up with everything in the $mode
variable, and the other 3 variables are empty.
If I isolate module_list() and a simple "while read" loop into a standalone
script, like this:
module_list()
{
...
}
module_list "$@" |
while read mode sha1 stage sm_path
do
echo - $mode - $sha1 - $stage - $sm_path -
done
It works -- each individual variable is set properly.
It seems that the problem only occurs inside git-submodule.sh.
Any ideas?
M.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 17:44 Weird problem with git-submodule.sh Marc Branchaud
@ 2012-12-07 17:54 ` Junio C Hamano
2012-12-07 18:03 ` Marc Branchaud
0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2012-12-07 17:54 UTC (permalink / raw
To: Marc Branchaud; +Cc: Git Mailing List
Marc Branchaud <marcnarc@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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 17:54 ` Junio C Hamano
@ 2012-12-07 18:03 ` Marc Branchaud
2012-12-07 19:11 ` Junio C Hamano
0 siblings, 1 reply; 19+ messages in thread
From: Marc Branchaud @ 2012-12-07 18:03 UTC (permalink / raw
To: Junio C Hamano; +Cc: Git Mailing List
On 12-12-07 12:54 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 18:03 ` Marc Branchaud
@ 2012-12-07 19:11 ` Junio C Hamano
2012-12-07 20:17 ` Marc Branchaud
0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2012-12-07 19:11 UTC (permalink / raw
To: Marc Branchaud; +Cc: Git Mailing List
Marc Branchaud <marcnarc@xiplink.com> writes:
> On 12-12-07 12:54 PM, Junio C Hamano wrote:
>> Marc Branchaud <marcnarc@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...
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 19:11 ` Junio C Hamano
@ 2012-12-07 20:17 ` Marc Branchaud
2012-12-07 20:23 ` Junio C Hamano
2012-12-07 22:15 ` [PATCH] sh-setup: Explicitly set IFS to its default, instead of unsetting it marcnarc
0 siblings, 2 replies; 19+ messages in thread
From: Marc Branchaud @ 2012-12-07 20:17 UTC (permalink / raw
To: Junio C Hamano; +Cc: Git Mailing List
On 12-12-07 02:11 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> On 12-12-07 12:54 PM, Junio C Hamano wrote:
>>> Marc Branchaud <marcnarc@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 <gitster@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 <adranse@oanda.com>.
Signed-off-by: Junio C Hamano <gitster@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 <space><tab><newline> string.)
M.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 20:17 ` Marc Branchaud
@ 2012-12-07 20:23 ` Junio C Hamano
2012-12-07 20:44 ` Marc Branchaud
2012-12-07 21:01 ` Marc Branchaud
2012-12-07 22:15 ` [PATCH] sh-setup: Explicitly set IFS to its default, instead of unsetting it marcnarc
1 sibling, 2 replies; 19+ messages in thread
From: Junio C Hamano @ 2012-12-07 20:23 UTC (permalink / raw
To: Marc Branchaud; +Cc: Git Mailing List
Marc Branchaud <marcnarc@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 <adranse@oanda.com>.
>
> Signed-off-by: Junio C Hamano <gitster@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 20:23 ` Junio C Hamano
@ 2012-12-07 20:44 ` Marc Branchaud
2012-12-07 21:08 ` Junio C Hamano
2012-12-07 21:01 ` Marc Branchaud
1 sibling, 1 reply; 19+ messages in thread
From: Marc Branchaud @ 2012-12-07 20:44 UTC (permalink / raw
To: Junio C Hamano; +Cc: Git Mailing List
On 12-12-07 03:23 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@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 <adranse@oanda.com>.
>>
>> Signed-off-by: Junio C Hamano <gitster@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 20:23 ` Junio C Hamano
2012-12-07 20:44 ` Marc Branchaud
@ 2012-12-07 21:01 ` Marc Branchaud
1 sibling, 0 replies; 19+ messages in thread
From: Marc Branchaud @ 2012-12-07 21:01 UTC (permalink / raw
To: Junio C Hamano; +Cc: Git Mailing List
On 12-12-07 03:23 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@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 <adranse@oanda.com>.
>>
>> Signed-off-by: Junio C Hamano <gitster@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 20:44 ` Marc Branchaud
@ 2012-12-07 21:08 ` Junio C Hamano
2012-12-07 22:34 ` [PATCH] sh-setup: work around "unset IFS" bug in some shells Junio C Hamano
2012-12-09 21:05 ` Weird problem with git-submodule.sh Stefano Lattarini
0 siblings, 2 replies; 19+ messages in thread
From: Junio C Hamano @ 2012-12-07 21:08 UTC (permalink / raw
To: Marc Branchaud; +Cc: Git Mailing List
Marc Branchaud <marcnarc@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH] sh-setup: Explicitly set IFS to its default, instead of unsetting it.
2012-12-07 20:17 ` Marc Branchaud
2012-12-07 20:23 ` Junio C Hamano
@ 2012-12-07 22:15 ` marcnarc
1 sibling, 0 replies; 19+ messages in thread
From: marcnarc @ 2012-12-07 22:15 UTC (permalink / raw
To: git; +Cc: Marc Branchaud
From: Marc Branchaud <marcnarc@xiplink.com>
Some sh implementations interpret "unset IFS" to mean IFS=''. This was
seen in FreeBSD 7.2's sh.
We need to make sure IFS has its default value: <space><tab><newline>.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
---
git-sh-setup.sh | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index ee0e0bc..56e6498 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -12,8 +12,11 @@
# But we protect ourselves from such a user mistake nevertheless.
unset CDPATH
-# Similarly for IFS
-unset IFS
+# Similarly for IFS, except that some sh implementations interpret "unset IFS"
+# as IFS='', so we need to set IFS explicitly to its POSIX default using
+# literal <space><tab><newline> characters.
+IFS='
+'
git_broken_path_fix () {
case ":$PATH:" in
--
1.8.0.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH] sh-setup: work around "unset IFS" bug in some shells
2012-12-07 21:08 ` Junio C Hamano
@ 2012-12-07 22:34 ` Junio C Hamano
2012-12-07 22:37 ` Marc Branchaud
2012-12-07 22:50 ` Andreas Schwab
2012-12-09 21:05 ` Weird problem with git-submodule.sh Stefano Lattarini
1 sibling, 2 replies; 19+ messages in thread
From: Junio C Hamano @ 2012-12-07 22:34 UTC (permalink / raw
To: Marc Branchaud; +Cc: Git Mailing List
With an unset IFS, field splitting is supposed to act as if IFS is
set to the usual SP HT LF, but Marc Branchaud reports that the shell
on FreeBSD 7.2 gets this wrong.
It is easy to set it to the default value manually, so let's do so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-sh-setup.sh | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index ee0e0bc..107c144 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -12,8 +12,11 @@
# But we protect ourselves from such a user mistake nevertheless.
unset CDPATH
-# Similarly for IFS
-unset IFS
+# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and
+# do not equate an unset IFS with IFS with the default, so here is
+# an explicit SP HT LF.
+IFS='
+'
git_broken_path_fix () {
case ":$PATH:" in
--
1.8.1.rc0.125.g5274144
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH] sh-setup: work around "unset IFS" bug in some shells
2012-12-07 22:34 ` [PATCH] sh-setup: work around "unset IFS" bug in some shells Junio C Hamano
@ 2012-12-07 22:37 ` Marc Branchaud
2012-12-07 22:50 ` Andreas Schwab
1 sibling, 0 replies; 19+ messages in thread
From: Marc Branchaud @ 2012-12-07 22:37 UTC (permalink / raw
To: Junio C Hamano; +Cc: Git Mailing List
I like your patch's subject line better than mine.
M.
On 12-12-07 05:34 PM, Junio C Hamano wrote:
> With an unset IFS, field splitting is supposed to act as if IFS is
> set to the usual SP HT LF, but Marc Branchaud reports that the shell
> on FreeBSD 7.2 gets this wrong.
>
> It is easy to set it to the default value manually, so let's do so.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> git-sh-setup.sh | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/git-sh-setup.sh b/git-sh-setup.sh
> index ee0e0bc..107c144 100644
> --- a/git-sh-setup.sh
> +++ b/git-sh-setup.sh
> @@ -12,8 +12,11 @@
> # But we protect ourselves from such a user mistake nevertheless.
> unset CDPATH
>
> -# Similarly for IFS
> -unset IFS
> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and
> +# do not equate an unset IFS with IFS with the default, so here is
> +# an explicit SP HT LF.
> +IFS='
> +'
>
> git_broken_path_fix () {
> case ":$PATH:" in
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] sh-setup: work around "unset IFS" bug in some shells
2012-12-07 22:34 ` [PATCH] sh-setup: work around "unset IFS" bug in some shells Junio C Hamano
2012-12-07 22:37 ` Marc Branchaud
@ 2012-12-07 22:50 ` Andreas Schwab
2012-12-07 22:58 ` Junio C Hamano
1 sibling, 1 reply; 19+ messages in thread
From: Andreas Schwab @ 2012-12-07 22:50 UTC (permalink / raw
To: Junio C Hamano; +Cc: Marc Branchaud, Git Mailing List
Junio C Hamano <gitster@pobox.com> writes:
> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and
> +# do not equate an unset IFS with IFS with the default, so here is
> +# an explicit SP HT LF.
> +IFS='
> +'
Trailing whitespace can easily get lost, so it's probably better to
stick a '' in here. The sequence <space><tab> is also easily being
mangled to <tab>.
IFS=' '' ''
'
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] sh-setup: work around "unset IFS" bug in some shells
2012-12-07 22:50 ` Andreas Schwab
@ 2012-12-07 22:58 ` Junio C Hamano
2012-12-08 9:25 ` Andreas Schwab
0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2012-12-07 22:58 UTC (permalink / raw
To: Andreas Schwab; +Cc: Marc Branchaud, Git Mailing List
Andreas Schwab <schwab@linux-m68k.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and
>> +# do not equate an unset IFS with IFS with the default, so here is
>> +# an explicit SP HT LF.
>> +IFS='
>> +'
>
> Trailing whitespace can easily get lost
The comment above the assingment spell the character names out for
that exact reason. Honestly, I think
> IFS=' '' ''
> '
is a lot harder to read. If we were writing in bash, we would
probably use $' \t\n' but because we aren't, the best you can do
with your approach is what you wrote, but it would make the reader
wonder what these empty '' are there for and how many spaces are in
between the ''<string here>'' pair.
In other words, I agree with your concerns, but I do not think your
rewrite helps very much.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] sh-setup: work around "unset IFS" bug in some shells
2012-12-07 22:58 ` Junio C Hamano
@ 2012-12-08 9:25 ` Andreas Schwab
0 siblings, 0 replies; 19+ messages in thread
From: Andreas Schwab @ 2012-12-08 9:25 UTC (permalink / raw
To: Junio C Hamano; +Cc: Marc Branchaud, Git Mailing List
Junio C Hamano <gitster@pobox.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and
>>> +# do not equate an unset IFS with IFS with the default, so here is
>>> +# an explicit SP HT LF.
>>> +IFS='
>>> +'
>>
>> Trailing whitespace can easily get lost
>
> The comment above the assingment spell the character names out for
> that exact reason. Honestly, I think
That won't help if you don't look for it. The loss can easily happen
while you are in a different part of the file.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-07 21:08 ` Junio C Hamano
2012-12-07 22:34 ` [PATCH] sh-setup: work around "unset IFS" bug in some shells Junio C Hamano
@ 2012-12-09 21:05 ` Stefano Lattarini
2012-12-12 19:10 ` Phil Hord
1 sibling, 1 reply; 19+ messages in thread
From: Stefano Lattarini @ 2012-12-09 21:05 UTC (permalink / raw
To: Junio C Hamano; +Cc: Marc Branchaud, Git Mailing List
Hi Junio, Marc.
On 12/07/2012 10:08 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-09 21:05 ` Weird problem with git-submodule.sh Stefano Lattarini
@ 2012-12-12 19:10 ` Phil Hord
2012-12-12 19:44 ` Junio C Hamano
0 siblings, 1 reply; 19+ messages in thread
From: Phil Hord @ 2012-12-12 19:10 UTC (permalink / raw
To: Stefano Lattarini; +Cc: Junio C Hamano, Marc Branchaud, Git Mailing List
Marc Branchaud <marcnarc@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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-12 19:10 ` Phil Hord
@ 2012-12-12 19:44 ` Junio C Hamano
2012-12-12 23:12 ` Phil Hord
0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2012-12-12 19:44 UTC (permalink / raw
To: Phil Hord; +Cc: Stefano Lattarini, Marc Branchaud, Git Mailing List
Phil Hord <phil.hord@gmail.com> writes:
> Marc Branchaud <marcnarc@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Weird problem with git-submodule.sh
2012-12-12 19:44 ` Junio C Hamano
@ 2012-12-12 23:12 ` Phil Hord
0 siblings, 0 replies; 19+ messages in thread
From: Phil Hord @ 2012-12-12 23:12 UTC (permalink / raw
To: Junio C Hamano; +Cc: Stefano Lattarini, Marc Branchaud, Git Mailing List
On Wed, Dec 12, 2012 at 2:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Phil Hord <phil.hord@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
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-12-12 23:13 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-07 17:44 Weird problem with git-submodule.sh Marc Branchaud
2012-12-07 17:54 ` Junio C Hamano
2012-12-07 18:03 ` Marc Branchaud
2012-12-07 19:11 ` Junio C Hamano
2012-12-07 20:17 ` Marc Branchaud
2012-12-07 20:23 ` Junio C Hamano
2012-12-07 20:44 ` Marc Branchaud
2012-12-07 21:08 ` Junio C Hamano
2012-12-07 22:34 ` [PATCH] sh-setup: work around "unset IFS" bug in some shells Junio C Hamano
2012-12-07 22:37 ` Marc Branchaud
2012-12-07 22:50 ` Andreas Schwab
2012-12-07 22:58 ` Junio C Hamano
2012-12-08 9:25 ` Andreas Schwab
2012-12-09 21:05 ` Weird problem with git-submodule.sh Stefano Lattarini
2012-12-12 19:10 ` Phil Hord
2012-12-12 19:44 ` Junio C Hamano
2012-12-12 23:12 ` Phil Hord
2012-12-07 21:01 ` Marc Branchaud
2012-12-07 22:15 ` [PATCH] sh-setup: Explicitly set IFS to its default, instead of unsetting it marcnarc
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).