Re: [PATCH 1/6] i18n win32: add git-am eval_gettext variable prefix

[Johannes Sixt <j.sixt@viscovery.net>]

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