On Sat, Jul 24, 2021 at 04:35:30PM +0200, Jean-Jacques Brucker wrote: > Planning to use the /$"string/" feature in my bash code made me think too > much : https://github.com/foopgp/bash-libs/tree/main/i18n
The security problem with $"..." is known. Unfortunately, Chet seems set on the idea that $"..." should perform parameter expansions and command substitutions, simply because it looks like "...". (Also, apparently people have been using it that way in real life as well, which makes it even more complicated to change.) That doesn't leave us with a clear path forward. There's no way to get a translated string without performing unwanted expansions afterward on the translated value, simply because of the syntax characters that were selected. So, most people have simply written the whole thing off as a lost cause. The best advice I can give is, "if you need localization in your program, don't write it in bash". > ...what I really *love* to see in bash, is a /$'string'/ feature, which > doesn't parse any «`» or «$» characters. $'...' already exists, so you can't use that for localization. > Did you already discuss about that ? Is there a hope to use such powerful > syntax without introducing security issue ? https://mywiki.wooledge.org/BashFAQ/098 https://lists.gnu.org/archive/html/bug-bash/2009-02/msg00258.html https://lists.gnu.org/archive/html/bug-bash/2009-03/msg00000.html I'm sure there are other past discussions, but good luck trying to find them, when the $"..." feature has no official *name* and Google won't let you search for $" as a key string.
