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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: May 26, 2011, 14:59 UTC
Message-ID: <4DDE6AC9.9090003@viscovery.net>
In-Reply-To: <7vlixtzh1q.fsf@alter.siamese.dyndns.org>

Am 5/26/2011 16:13, schrieb Junio C Hamano:

Show 12 quoted lines

> 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