Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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.
--
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