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. But if we want to make this work on Windows I guess we can change things like $path and $repo to $windows_me_harder_path and $windows_me_harder_repo. -- 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