On 8/13/21 2:01 PM, Léa Gris wrote:
> I would have really loved if Bash expanded translations with its
> built-in printf using a `-g` flag for gettext and positional arguments
> support instead of expanding string literal translations.
>
> It would have allowed something like :
>
> ```sh
> #!/usr
On 8/13/21 12:14 PM, Jean-Jacques Brucker wrote:
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 u
Le 13/08/2021 à 18:14, Jean-Jacques Brucker écrivait :
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
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-pr
On 8/11/21 6:35 PM, Jean-Jacques Brucker wrote:
>
> Le 10/08/2021 à 17:22, Chet Ramey a écrit :
>> This is the current description:
>>
>> noexpand_translation
>> If set, bash encloses the translated results of $"..."
>> quoting in single quotes instead of
Le 10/08/2021 à 17:22, Chet Ramey a écrit :
This is the current description:
noexpand_translation
If set, bash encloses the translated results of $"..."
quoting in single quotes instead of double quotes. If
the string is not translate
On 8/10/21 2:56 PM, Mike Jonkmans wrote:
noexpand_translation
If set, bash encloses the translated results of $"..."
quoting in single quotes instead of double quotes. If
the string is not translated, this has no effect.
It will be in
On Tue, Aug 10, 2021 at 11:22:54AM -0400, Chet Ramey wrote:
> On 7/31/21 4:17 PM, Jean-Jacques Brucker wrote:
> >
> > Le 29/07/2021 à 21:08, Chet Ramey a écrit :
> >
> >> How about `noexpand_translation'?
> >
> > It sounds good ! (imho).
>
> This is the current description:
>
>noexpand
On 7/31/21 4:17 PM, Jean-Jacques Brucker wrote:
>
> Le 29/07/2021 à 21:08, Chet Ramey a écrit :
>
>> How about `noexpand_translation'?
>
> It sounds good ! (imho).
This is the current description:
noexpand_translation
If set, bash encloses the translated results of $"..
On 7/31/21 4:57 PM, Lawrence Velázquez wrote:
On Sat, Jul 31, 2021, at 4:17 PM, Jean-Jacques Brucker wrote:
The advantage of adding such variable is that we could use more easily
different mo files in a same bash execution :
(at least) one "legacy" (for /$"..."/) and (at least) one 'C-strings'
On Sat, Jul 31, 2021, at 4:17 PM, Jean-Jacques Brucker wrote:
> The advantage of adding such variable is that we could use more easily
> different mo files in a same bash execution :
>
> (at least) one "legacy" (for /$"..."/) and (at least) one 'C-strings'
> (for /$'...'/), which could then be s
Le 29/07/2021 à 21:08, Chet Ramey a écrit :
How about `noexpand_translation'?
It sounds good ! (imho).
IMHO bash already suffers of having too many options. And using, or
not, one of those often breaks compatibility.
It's not really a matter of having too many options, as long as the
de
On 7/29/21 4:33 PM, Eli Schwartz wrote:
On 7/24/21 2:48 PM, Chet Ramey wrote:
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
On 7/24/21 2:48 PM, Chet Ramey wrote:
> 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'/ fea
On 7/27/21 4:40 PM, Jean-Jacques Brucker wrote:
Le 27/07/2021 à 16:39, Chet Ramey a écrit :
That's not a good name. It provides no insight about the option or its
purpose. Maybe something like `quote_translation'.
You are right. And I was sorely lacking in imagination.
How about `noexpand_tr
I configured the list to only receive digests of bug-bash mailing list.
So I didn't read your message before looking up myself into archive :
https://lists.gnu.org/archive/html/bug-bash/2021-07/msg00059.html
> So, most people have simply written the whole thing off as a lost cause.
> The best a
On Tue, Jul 27, 2021 at 10:44:09PM +0200, Jean-Jacques Brucker wrote:
>
> I like what you wrote 12 years ago (
> https://lists.gnu.org/archive/html/bug-bash/2009-02/msg00258.html ). IMHO,
> it could have change some people's mind about bash, and could have saved
> developer energy.
>
>
> > $'...
I configured the list to only receive digests of bug-bash mailing list.
So I didn't read your message before looking up myself into archive :
https://lists.gnu.org/archive/html/bug-bash/2021-07/msg00059.html
> So, most people have simply written the whole thing off as a lost cause.
> The best a
Le 27/07/2021 à 16:39, Chet Ramey a écrit :
That's not a good name. It provides no insight about the option or its
purpose. Maybe something like `quote_translation'.
You are right. And I was sorely lacking in imagination.
That's not backwards compatible, so the best thing for you to do would b
On 7/24/21 4:45 PM, Jean-Jacques Brucker wrote:
>
> 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.
OK, so the result is e
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,
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
wi
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 «$» character
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 $
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 ther
25 matches
Mail list logo
