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

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j.sixt@viscovery.net> writes:

> I gather that the actual substitution of variable values is done by
> sh-i18n--envsubst, and not by the shell (right?). Let's look at an example:
>
> 	git sh-i18n--envsubst --variables '$foo and $bar'
>
> produces
>
> 	foo
> 	bar
>
> What if it produced
>
> 	GIT_I18N_VARIABLE_foo=$foo
> 	GIT_I18N_VARIABLE_bar=$bar
> 	export GIT_I18N_VARIABLE_foo GIT_I18N_VARIABLE_bar
>
> then the definition of eval_gettext() would look like
>
> eval_gettext () {
> 	printf "%s" "$1" | (
> 		export PATH
> 		eval "$(git sh-i18n--envsubst --variables "$1")"
> 		git sh-i18n--envsubst "$1"
> 	)
> }
>
> and the second call of sh-i18n--envsubst should replace $foo and $bar that
> it sees on stdin by the values of GIT_I18N_VARIABLE_foo and
> GIT_I18N_VARIABLE_bar from the environment.
>
> What do you think?

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?

If that is a non-issue, I think your change is a good thing to do.