Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx> writes:
> Add a git-sh-i18n--envsubst program which is a stripped-down version
> of the GNU envsubst(1) program that comes with GNU gettext for use in
> the eval_gettext() fallback, instead of using a clever (but broken)
> printf + eval + printf trick.
>
> In a previous incarnation of the gettext series I implemented the
> eval_gettext() fallback like this:
>
> eval_gettext() {
> gettext_out=$(gettext "$1")
> gettext_eval="printf '%s' \"$gettext_out\""
> printf "%s" "`eval \"$gettext_eval\"`"
> }
>
> This was clever,...
The incoming string to this function is an arbitrary string and it is
asked to interpolate variables $var in it, without any other restriction
in the string. If we want to interpolate $var using shell eval, we have
to somehow put it in the dq context, but all other interpolation done
inside dq context would also be applied to the piece of the string by the
eval, including backslashes, $(command substitution--horrors), etc., which
we would have needed to add more quotes to selected places in the string
(read: parse and find what the shell would interpolate ourselves) to
prevent them from happening.
In hindsight, it should have been clear to all of us from day one that
shell eval based approach would have never worked.
I suspect that the use of envsubst (especially the part that gives the
string itself to envsubst) is not quite right. What if the message wanted
to say something like this?
Look at $HOME/.gitconfig and find definition for $var variable.
where we want to show $HOME _literally_, while substituting $var for the
name of the variable? The underlying envsubst allows you to do so by
telling it which the variables are to be substituted.
s='Look at $HOME/.gitconfig and find definition of $var variable.'
HOME=/home/junio
var=core.i18n
(
export HOME var ;# no need for HOME, but just an illustration
echo "$s" | envsubst '$var'
)
but eval_gettext interface doesn't seem to be expressive enough to do this;
you would let it scan the whole "$s" and end up substituting $HOME, no?
Perhaps it is not an issue in real life; after all eval_gettext interface
is not something you invented in 5 minutes without thinking deeply, but is
what you plan to use from outside codebase that presumably has seen a wide
use in the field, and it may be just that I am worried too much about an
implausible corner case, but I thought I should bring it up.
Thanks.
--
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