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
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
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
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
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 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
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
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
Playing with flock to securely access to a file shared by multiple
process. I noticed there are no documented way to do an lseek on an
opened fd with bash :
#!/bin/bash
exec 18<>/tmp/resource
flock 18
# (...) read and analyze the resource file
# ?? there is no documented way to seek or rewind in
playing with flock to securely access to a file shared by multiple
process. I noticed there are no documented way to do an lseek on an
opened fd with bash :
#!/bin/bash
exec 18<>/tmp/resource
flock 18
# (...) read and analyze the resource file
# ?? there is no documented way to seek or rewind in
100 % reproducible on my Debian, package version 5.1-2:
$ echo "dc30a6d79f3b47e310b8b9f5fbadba57" | tee >( xxd -r -p | base64)
| tee >(xxd -r -p | basenc --base64url )
dc30a6d79f3b47e310b8b9f5fbadba57
3DCm1587R+MQuLn1+626Vw==
3DCm1587R-MQuLn1-626Vz0Vhw==
I first thought I missed somethin
quot; | tee >( head -c 4 ; echo ;
ls -l /proc/self/fd ) | { tee >(xxd -r -p | basenc --base64 ) ; ls -l
/proc/self/fd ; }
Cheers,
Le 29/01/2021 à 14:50, Chet Ramey a écrit :
On 1/28/21 6:33 PM, Jean-Jacques Brucker wrote:
100 % reproducible on my Debian, package version 5.1-2:
12 matches
Mail list logo
