gettext feature request
Planning to use the /$"string/" feature in my bash code made me think too much : https://github.com/foopgp/bash-libs/tree/main/i18n ...what I really *love* to see in bash, is a /$'string'/ feature, which doesn't parse any «`» or «$» characters. Did you already discuss about that ? Is there a hope to use such powerful syntax without introducing security issue ? Cheers, OpenPGP_0xA3983A40D1458443.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: gettext feature request
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/msg0.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.
Re: gettext feature request
On 7/24/21 10:35 AM, 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 ...what I really *love* to see in bash, is a /$'string'/ feature, which doesn't parse any «`» or «$» characters. So you want a translation feature without any further interpretation? Or one just without command substitution? What about an option to enable this variant behavior? What do you think would be a suitable name? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
should bashdb be included w/bash?
Not entirely sure how, but have been running 5.1.8(3)-release which seems fine...up until I wanted to single step a script... bashdb ...and saw /usr/share/bashdb/command/set_sub/dollar0.sh: line 23: enable: dynamic loading not available (/tmp/rearrange_files.sh:4): 4: shopt -s expand_aliases bashdb<0> dynamic loading not available?...poke poke poke...um oh: bash debugger, bashdb, release 4.4-0.94 doesn't seem to be same as bash...hmm...that's probably not good. Probably my local distro ...looked for a bashdb package...nep. oh...it's just out there in the wild, sorta, well on a gnu related site...similar. Guess it wasn't ever packaged as a separate thing. Does it need to be? (Yeah, maybe?, I don't care, but some might) But maybe it should be included w/bash (at least as far as source goes), and become maybe an --enable-bashdb option at build time? (or --disable-bashdb to include by default?). Isn't debugging a default in many (most?) languages? perl, as an interpreted language seems to include perldb. At least if the option is included @ build time, it isn't so likely that it would _accidently_ be left out... which would be useful/convenient IMLBO...(In_My_Lazy_Butt_Opinion) Eh? Doesn't seem like it would be hard... ???
Re: should bashdb be included w/bash?
On 7/24/21 3:09 PM, L A Walsh wrote: Not entirely sure how, but have been running 5.1.8(3)-release which seems fine...up until I wanted to single step a script... bashdb ...and saw /usr/share/bashdb/command/set_sub/dollar0.sh: line 23: enable: dynamic loading not available (/tmp/rearrange_files.sh:4): 4: shopt -s expand_aliases bashdb<0> It looks like your system doesn't have the right dlopen support for dynamic loading builtins, so bash didn't compile it in. dynamic loading not available?...poke poke poke...um oh: bash debugger, bashdb, release 4.4-0.94 doesn't seem to be same as bash...hmm...that's probably not good. It may or may not mean anything. Probably my local distro ...looked for a bashdb package...nep. oh...it's just out there in the wild, sorta, well on a gnu related site...similar. There are a number of packaged versions of bashdb, but I don't know how current they are. Guess it wasn't ever packaged as a separate thing. Does it need to be? (Yeah, maybe?, I don't care, but some might) But maybe it should be included w/bash (at least as far as source goes), and become maybe an --enable-bashdb option at build time? I'm not interested in maintaining bashdb (and no one has asked me to). My goal is that the bash testing cycle is long enough to allow the bashdb developers (I don't know them) to align their testing with the bash testing, so the bashdb that's available when, say, bash-5.2 gets released has been tested against bash-5.2. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: gettext feature request
Le 24/07/2021 à 20:48, Chet Ramey a écrit :
So you want a translation feature without any further interpretation? Or
one just without command substitution?
Translation feature without any further interpretation.
pros:
* eases interoperability of *.mo files (eg: may then be shared with
with C programs)
* more coherent with other single quoted string (would only differ by
interpreting escaped chars even if not used with printf or echo -e)
* implies better string factorization (force things like /printf
$'file %s is too big\n' .../ instead of /echo $'file $f is too big'/
and later /echo $'file ${fl[$n]} is too big'/)
I see no cons.
What about an option to enable this variant behavior? What do you think
would be a suitable name?
For testing purpose, option-name: *gettext*. But if possible, I would
prefer such feature enabled by default, then *nogettext* to disable.
As of today (bash 5.1.x), *-g* and *-G* are also available.
Cheers,
Jean-Jacques.
OpenPGP_0xA3983A40D1458443.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: gettext feature request
Le 24/07/2021 à 20:48, Chet Ramey écrivait : On 7/24/21 10:35 AM, 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 ...what I really *love* to see in bash, is a /$'string'/ feature, which doesn't parse any «`» or «$» characters. So you want a translation feature without any further interpretation? Or one just without command substitution? What about an option to enable this variant behavior? What do you think would be a suitable name? It'd be perfectly fine if non interpreted locale string was reserved for format string of the built-in printf, and supported positional arguments. Example: declare -- str='Hello World!' declare -i num=42 printf $"string: %1$s, int %2$d\n" "$str" $num Unchanged gettext string syntax $"string" but without variable and sub-shell expansion, and %n$ positional markers support when it is used as a printf format string. Would fix the security risks of variable expansion in gettext strings. Would not overlap $'c-style string' syntax. Would maintain variable expansion outside the printf format string context to maintain backward compatibility. -- Léa Gris
