On Mär 31 2025, Chet Ramey wrote:
> It's hard to see these as being useful if they're glibc-specific.
They are coming from ISO TR 14652 and 30112.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely
On Mär 26 2025, Andreas Kähäri wrote:
> The argument to "bash -c"
There is no "bash -c" in that command.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On 3/30/25 2:34 AM, Robert Elz wrote:
Date:Thu, 27 Mar 2025 17:22:03 -0400
From:Chet Ramey
Message-ID: <6da17a73-2aac-4fa5-9fa7-5bfff087d...@case.edu>
| The shell should assume that setting a shell variable means the
| user wants to modify the shell's local
On 3/29/25 4:52 PM, Lawrence Velázquez wrote:
Additional macro definitions, beginning with the characters
LC_ and an uppercase letter, may also be specified by the
implementation.
https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/basedefs/locale.h.html
Thank
On 3/31/25 12:52 PM, Andreas Schwab wrote:
On Mär 31 2025, Chet Ramey wrote:
It's hard to see these as being useful if they're glibc-specific.
They are coming from ISO TR 14652 and 30112.
OK. And when other systems support them, and they get standardized, it will
be time to revisit the issu
Date:Thu, 27 Mar 2025 17:22:03 -0400
From:Chet Ramey
Message-ID: <6da17a73-2aac-4fa5-9fa7-5bfff087d...@case.edu>
| The shell should assume that setting a shell variable means the
| user wants to modify the shell's locale settings.
Yes, of course, the question is
On Sat, Mar 29, 2025, at 4:52 PM, Lawrence Velázquez wrote:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/locale.h;hb=glibc-2.41#l33
> https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/langinfo.h;hb=glibc-2.41#l584
> https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/loca
On Sat, Mar 29, 2025, at 2:25 PM, Chet Ramey wrote:
> How does a locale doing this expose the category to the programmer?
> I suppose all possible additional locale categories have to be available
> to setlocale() somehow, via and the documentation.
Yeah, looks like POSIX explicitly permits that:
On 3/29/25 12:05 AM, Lawrence Velázquez wrote:
On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote:
On 3/26/25 6:29 PM, Robert Elz wrote:
LANG is generally just the fallback for categories that haven't been
set to something else. For this, assume the LC_ALL had never been
set (setting LANG aft
On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote:
> On 3/26/25 6:29 PM, Robert Elz wrote:
>> LANG is generally just the fallback for categories that haven't been
>> set to something else. For this, assume the LC_ALL had never been
>> set (setting LANG after that is set should probably just do n
On 3/26/25 6:29 PM, Robert Elz wrote:
Date:Wed, 26 Mar 2025 16:05:57 -0400
From:Chet Ramey
Message-ID:
| There is a precedence hierarchy associated with locale environment
| variables, since setting and unsetting environment variables is under
| the use
Le 26/03/2025 à 21:18, Chet Ramey écrivait :
I think you're misunderstanding the order of execution here.
What additions would you suggest? The order of execution is described in
SIMPLE COMMAND EXPANSION. The locale variables and their precedence
hierarchy are described in Shell Variables with t
Date:Wed, 26 Mar 2025 16:05:57 -0400
From:Chet Ramey
Message-ID:
| There is a precedence hierarchy associated with locale environment
| variables, since setting and unsetting environment variables is under
| the user's control.
This brings up an unrelated, bu
On 3/26/25 8:20 AM, Léa Gris wrote:
I am onto something here :
No, not really. It's pretty simple.
$ LC_ALL=C bash -c 'locale; printf "\\nEnvironment variable: LC_NUMERIC=%s\
\n" "$LC_NUMERIC"'
LC_ALL overrides LC_NUMERIC, as explained in the POSIX reference I sent.
Setting LC_ALL doesn't c
On 3/26/25 8:09 AM, Léa Gris wrote:
I wonder if locale is switched accordingly to environment variables, but
environment variables may not automatically switch to the new locale.
There is a precedence hierarchy associated with locale environment
variables, since setting and unsetting environm
On 3/26/25 6:52 AM, Léa Gris wrote:
LANG=C LC_NUMERIC=C printf '%s\t%f\t%f\n' "$LC_NUMERIC" 3.141592654
3,141592654
Outputs:
bash: printf: 3,141592654: invalid number
fr_FR.UTF-8 3.141593 3.00
In this particular case, the expansion of LC_NUMERIC is performed before
the `printf' bu
On 3/26/25 7:54 AM, Andreas Kähäri wrote:
On my Alpine system (bash 5.3.37), LC_NUMERIC is unset, and setting
LC_ALL does not automagically set LC_NUMERIC in "bash -c":
% LC_ALL=C bash -c 'echo "$LC_NUMERIC"'
(blank line output)
% LANG=C bash -c 'echo "$LC_NUMERIC"'
Le 26/03/2025 à 12:54, Andreas Kähäri wrote :
On my Alpine system (bash 5.3.37), LC_NUMERIC is unset, and setting
LC_ALL does not automagically set LC_NUMERIC in "bash -c":
% LC_ALL=C bash -c 'echo "$LC_NUMERIC"'
(blank line output)
% LANG=C bash -c 'echo "$LC_NUMERIC"'
On Wed, Mar 26, 2025 at 01:35:12PM +0100, Andreas Schwab wrote:
> On Mär 26 2025, Andreas Kähäri wrote:
>
> > The argument to "bash -c"
>
> There is no "bash -c" in that command.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3
On Wed, Mar 26, 2025 at 13:09:45 +0100, Léa Gris wrote:
> $ LC_ALL=C locale
> LANG=fr_FR.UTF-8
> LANGUAGE=fr_FR:fr_CA:en
> LC_CTYPE="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_COLLATE="C"
> LC_MONETARY="C"
> LC_MESSAGES="C"
> LC_PAPER="C"
> LC_NAME="C"
> LC_ADDRESS="C"
> LC_TELEPHONE="C"
> LC_MEASUREME
I am onto something here :
$ LC_ALL=C bash -c 'locale; printf "\\nEnvironment variable:
LC_NUMERIC=%s\\n" "$LC_NUMERIC"'
Output:
LANG=fr_FR.UTF-8
LANGUAGE=fr_FR:fr_CA:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="
On Wed, Mar 26, 2025 at 12:19:48PM +0100, Andreas Schwab wrote:
> On Mär 26 2025, Léa Gris wrote:
>
> > Even though LC_NUMERIC=C is used to correctly parse 3.141592654, the
> > expansion of $LC_NUMERIC still prints its original value (fr_FR.UTF-8).
>
> That is expected. The reference to LC_NUMER
On Mär 26 2025, Léa Gris wrote:
> Even though LC_NUMERIC=C is used to correctly parse 3.141592654, the
> expansion of $LC_NUMERIC still prints its original value (fr_FR.UTF-8).
That is expected. The reference to LC_NUMERIC is expanded before the
command execution is started (which includes putti
23 matches
Mail list logo
