Am 5/26/2011 16:13, schrieb Junio C Hamano: > This started on windows that confuses between $path and $PATH, we wouldn't > be doing this, right? In git-submodule.sh uses $path variable for > something other than the search-path, and the definition updated by you > would become in the larger picture: > > path=... ;# git-submodule uses the variable for not-a-search-path > _I18N__path=$path > export _I18N__path > git sh-i18n--envsubst "... $_I18N__path" > > Is the RHS of the second assignment safe on Windows? Are environment > variables case insane but normal variables are safe? Yes, the second assignment is safe, because at this point everything is internal to bash; it does the right thing. Problems start only when exported variables are transported from bash to another process. But ... wait a minute - I've another idea! bash -c "path=z env" *does* list both 'path' and 'PATH' ... hack hack ... and so does a home-grown equivalent of 'env', both for MinGW and Visual Studio. It looks like the environment was transfered just fine, only the *lookup* by getenv() was case-insensitive. This means we would just have to supply a POSIX conformant getenv() for sh-i18n--envsubst. I can write one, no problem; and, Ævar, I'm awfully sorry for sending you in the wrong direction. -- Hannes -- 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