bash 2.0 or newer has a special shorthand for translating a
string and substituting variable values in it:
the use of this construct is discouraged, due to the security
holes it opens and due to its portability problems.
The security holes of
$"..." come from the fact that after looking up
the translation of the string,
bash processes it like it processes
any double-quoted string: dollar and backquote processing, like ‘
0x60. For example, the byte sequence
\xe0\x60is a single character in these locales. Many versions of
bash(all versions up to bash-2.05, and newer versions on platforms without
mbsrtowcs()function) don’t know about character boundaries and see a backquote character where there is only a particular Chinese character. Thus it can start executing part of the translation as a command list. This situation can occur even without the translator being aware of it: if the translator provides translations in the UTF-8 encoding, it is the
gettext()function which will, during its conversion from the translator’s encoding to the user’s locale’s encoding, produce the dangerous
"$(...)"in her translations. The enclosed strings would be executed as command lists by the shell.
The portability problem is that
bash must be built with
internationalization support; this is normally not the case on systems
that don’t have the
gettext() function in libc.