Re: gettext feature request

[Jean-Jacques Brucker]

Le 12/08/2021 à 16:29, Chet Ramey a écrit :

On 8/11/21 6:35 PM, Jean-Jacques Brucker wrote:

Thank a lot Chet.

I still think it would have been more consistent to extend the $'...' syntax.

Why would it be more consistent to add translation to a quoting syntax that
didn't have it than to post-process translations in a different way?

Chet

I'm probably less familiar with the history of shells and bash than you (and

others on this mailing list), but it seems to me that:

First were the chains:
 * '...' who did not expand anything
 * "..." which expanded the syntaxes $VAR and the unfortunate `...` [1]

Then the syntax $"..." was introduced, then the syntax $'...' (bash 2.X).


string"


prior to shells, and bash is itself written in C).


than the translation feature).


(I'm probably dreaming ... but do we ever know ?). Then we could have:

 1. "...": expanded shell string
 2. '...': unexpanded shell string
 3. `...`: unexpanded C string (today $'...' :-/ )

and logically:


 5. $'...': translated unexpanded shell string (soon released $"..." with
    shopt noexpand_translation !?)
 6. $`...`: translated unexpanded C string (the feature[2] I dream of the
    most, maybe soon $'...' with a shopt like translate_c_string ?)

[1]: cf. https://www.grymoire.com/Unix/Sh.html#uh-8a


existing translation chains. Not only to dig into the many existing C

As the character '$' means "interprets (synonym: translates) what follows", it seems to me quite consistent that $"..." means "translates the entire following Conversely, the syntax $'...' seems to me much less consistent. (Reminder: C is However, the "C-string" feature is very useful (and nowadays probably more used In absolute terms, if one day we would list all the historical design errors, dare to break some compatibilities, and manage to establish new shell standards  4. $"...": translated expanded shell string (to NOT use for security reasons) [2]: What I like the most about this feature, and that I could directly reuse translations, but also not to redo the translations when, for various reasons (performance, etc.), we are forced to rewrite bash code in a compiled language.

OpenPGP_signature
Description: OpenPGP digital signature