On Fri, May 13, 2011 at 10:21 AM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > On Thu, May 12, 2011 at 16:20, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: >> Am 5/12/2011 15:48, schrieb Ævar Arnfjörð Bjarmason: >>> On Thu, May 12, 2011 at 10:08, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: >>>> Am 5/8/2011 14:20, schrieb Ævar Arnfjörð Bjarmason: >>>>> - say "Submodule '$name' ($url) registered for path '$path'" >>>>> + say "$(eval_gettext "Submodule '\$name' (\$url) registered for path '\$path'")" >>>> >>>> On Windows, we have a problem with messages like this (and many others) >>>> that reference $path. eval_gettext has to export 'path', but on Windows >>>> environment variables are case-insensitive. In the substitution, this >>>> happens to pick the value of 'PATH' rather than of 'path'... Can you do >>>> something about this? >>>> >>>> Of course, the problem is not limited to 'path' at all, but it is a >>>> prominent example discovered by the test suite. >>> >>> I didn't know Windows had that limitation. We can easily work around >>> it by just renaming $path to something else (e.g. $filepath). >>> >>> Since we do: >>> >>> export PATH $(git sh-i18n--envsubst --variables "$1"); >>> >>> I assume this problem only occurs with variables that match >>> /^path$/i. Or are there other problems on Windows? >> >> It is *not* limited to PATH. There can be other variables in the >> environment that are the same name as some that are exported in this >> statement. Here's a brief test: >> >> --- 8< --- >> $ cat git-test >> #!/bin/sh >> >> . git-sh-setup >> . git-sh-i18n >> >> AppData=myappdata >> username=myUserName >> proMPT=myprompt >> >> echo "$(eval_gettext "AppData: '\$AppData' >> username: \$username >> proMPT: \$proMPT >> path: '\$path'")" >> >> $ git --exec-path=. test >> AppData: 'C:\Dokumente und Einstellungen\jsixt\Anwendungsdaten' >> username: jsixt >> proMPT: $P$G >> path: >> 'd:/Src/mingw-git/.;d:\Src\mingw-git;d:\Src\mingw-git\;d:\Src\mingw-git;...snip...;.' >> --- 8< --- > > That's interesting. I thought that the problem would only be with > PATH, since we'd clobber the other environment variables when we do > the export in git-sh-i18n. > > But evidently not, but I don't quite grok why. > > Anyway, this behavior seems un-POSIX compliant, and I'd been assuming > that our shell scripts were POSIX shellscripts when I wrote this. May I remind you of the first rule in Documentation/CodingGuidelines? - Most importantly, we never say "It's in POSIX; we'll happily ignore your needs should your system not conform to it." We live in the real world. -- 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