info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Does "LC_ALL=C" work on all shells?
39 views
Skip to first unread message
Franco Martelli
Feb 13, 2024, 3:50:07 PMFeb 13
to
Hi,
If I want English output of an application I set the environment
variable LC_ALL to "C" inline of the command e.g.:
~# LC_ALL=C apt install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
If I don't set the variable the apt command return output localized:
~# apt install
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
This is useful when it's needed to submit a bug report or to speak with
other people in one international mailing list like this :) (apropos
sorry for my English).
So the question is: does anybody know if this syntax works on all shells
other than bash? csh, korn, dash, zsh …
Thanks in advance, kind regards
--
Franco Martelli
If I want English output of an application I set the environment
variable LC_ALL to "C" inline of the command e.g.:
~# LC_ALL=C apt install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
If I don't set the variable the apt command return output localized:
~# apt install
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
This is useful when it's needed to submit a bug report or to speak with
other people in one international mailing list like this :) (apropos
sorry for my English).
So the question is: does anybody know if this syntax works on all shells
other than bash? csh, korn, dash, zsh …
Thanks in advance, kind regards
--
Franco Martelli
Greg Wooledge
Feb 13, 2024, 4:00:08 PMFeb 13
to
On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote:
> ~# LC_ALL=C apt install
> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …
This syntax works in all the Bourne family shells, which is all of the
above *except* csh.
In csh, you need to use env. Like this:
% env LC_ALL=C apt install
This works in all shells, at the cost of being slightly less efficient.
> ~# LC_ALL=C apt install
> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …
above *except* csh.
In csh, you need to use env. Like this:
% env LC_ALL=C apt install
This works in all shells, at the cost of being slightly less efficient.
Nicolas George
Feb 13, 2024, 4:00:08 PMFeb 13
to
Franco Martelli (12024-02-13):
better making this the default. Translations of software are often
mediocre or worse. (I remember when the French translation of df broke
the alignment of columns.) Use the software in its original version and
you will not have to guess if you misunderstood or if the translator
did.
> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …
apt-get install csh
csh
LC_CTYPE=C ls /doesnotexist
^D
apt-get purge csh
Repeat with other shells. And then tell us what you found out.
Regards,
--
Nicolas George
> This is useful when it's needed to submit a bug report or to speak with
> other people in one international mailing list like this :) (apropos sorry
> for my English).
Your English does not look bad. And therefore you would probably be
> other people in one international mailing list like this :) (apropos sorry
> for my English).
better making this the default. Translations of software are often
mediocre or worse. (I remember when the French translation of df broke
the alignment of columns.) Use the software in its original version and
you will not have to guess if you misunderstood or if the translator
did.
> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …
csh
LC_CTYPE=C ls /doesnotexist
^D
apt-get purge csh
Repeat with other shells. And then tell us what you found out.
Regards,
--
Nicolas George
Nicolas George
Feb 13, 2024, 4:10:07 PMFeb 13
to
Greg Wooledge (12024-02-13):
> % env LC_ALL=C apt install
>
> This works in all shells, at the cost of being slightly less efficient.
And even without a shell.
Regards,
--
Nicolas George
> This syntax works in all the Bourne family shells, which is all of the
> above *except* csh.
>
> In csh, you need to use env.
No, ( setenv var something ; command ) works with csh.
> above *except* csh.
>
> In csh, you need to use env.
> % env LC_ALL=C apt install
>
> This works in all shells, at the cost of being slightly less efficient.
Regards,
--
Nicolas George
John Conover
Feb 13, 2024, 4:30:07 PMFeb 13
to
Franco Martelli writes:
>
> If I want English output of an application I set the environment
> variable LC_ALL to "C" inline of the command e.g.:
>
.
>
> If I want English output of an application I set the environment
> variable LC_ALL to "C" inline of the command e.g.:
>
.
.
>
> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …
>
Hi Franco.
>
> So the question is: does anybody know if this syntax works on all shells
> other than bash? csh, korn, dash, zsh …
>
egrep ALL .bashrc
LC_ALL=C
set | egrep ALL
LC_ALL=C
dash
set | egrep ALL
So, apparently not, (I don't have it set in /etc/profile, which is
read when dash is invoked; initializing in ~/.profile would work,
too. Probably the same in csh, korn, zsh ...)
John
--
John Conover, con...@panix.com, http://www.johncon.com/
Nicolas George
Feb 13, 2024, 4:30:07 PMFeb 13
to
John Conover (12024-02-13):
the command”.
--
Nicolas George
> > variable LC_ALL to "C" inline of the command e.g.:
^^^^^^^^^^^^^^^^^^^^^
> egrep ALL .bashrc
> LC_ALL=C
>
> set | egrep ALL
> LC_ALL=C
>
> dash
> set | egrep ALL
You missed part of the question, what you are showing is not “inline of
> LC_ALL=C
>
> set | egrep ALL
> LC_ALL=C
>
> dash
> set | egrep ALL
the command”.
--
Nicolas George
Greg Wooledge
Feb 13, 2024, 4:50:06 PMFeb 13
to
On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote:
> egrep ALL .bashrc
> LC_ALL=C
This has gone pretty far off the rails, but here we are. Let's address
this.
DO NOT set LC_ALL in your .bashrc or equivalent files. This is a horrible
idea. LC_ALL should only be used in single commands as a full-powered
override, for example when you want to report a bug, and need the output
to be normalized to the "C" locale.
In your everyday operations, you should use the LANG variable for the
locale that most closely matches your needs, and individual LC_*
variables (such as LC_TIME) for specific overrides. Setting it up this
way allows you to override with LC_ALL when needed, *and* it allows you
to fine-tune your preferences.
For example, let's say you wanted the C locale for most things, but
the en_US.utf8 locale for one particular setting (let's say LC_TIME).
You can do this with:
LANG=C LC_TIME=en_US.utf8
but if you try it this way:
LC_ALL=C LC_TIME=en_US.utf8
then it won't work, because LC_ALL overrides everything. Your LC_TIME
setting will have no effect.
Of course, *none* of this is relevant to the original question, which
was about the shell syntax for overriding environment variables on a
single command.
> egrep ALL .bashrc
> LC_ALL=C
This has gone pretty far off the rails, but here we are. Let's address
this.
DO NOT set LC_ALL in your .bashrc or equivalent files. This is a horrible
idea. LC_ALL should only be used in single commands as a full-powered
override, for example when you want to report a bug, and need the output
to be normalized to the "C" locale.
In your everyday operations, you should use the LANG variable for the
locale that most closely matches your needs, and individual LC_*
variables (such as LC_TIME) for specific overrides. Setting it up this
way allows you to override with LC_ALL when needed, *and* it allows you
to fine-tune your preferences.
For example, let's say you wanted the C locale for most things, but
the en_US.utf8 locale for one particular setting (let's say LC_TIME).
You can do this with:
LANG=C LC_TIME=en_US.utf8
but if you try it this way:
LC_ALL=C LC_TIME=en_US.utf8
then it won't work, because LC_ALL overrides everything. Your LC_TIME
setting will have no effect.
Of course, *none* of this is relevant to the original question, which
was about the shell syntax for overriding environment variables on a
single command.
Will Mengarini
Feb 13, 2024, 5:00:06 PMFeb 13
to
> On Tue, Feb 13, 2024 at 09:47:38PM +0100, Franco Martelli wrote:
>> ~# LC_ALL=C apt install
>> [... works on ...] all shells other than bash? csh, korn, dash, zsh ...
>> ~# LC_ALL=C apt install
* Greg Wooledge <gr...@wooledge.org> [24-02/13=Tu 15:59 -0500]:
> [...] all the Bourne family shells [...]
>
> In csh, you need to use env. Like this:
>
> % env LC_ALL=C apt install
>
> This works in all shells, at the cost of being slightly less efficient.
* Nicolas George <geo...@nsup.org> [24-02/13=Tu 22:04 +0100]:
> % env LC_ALL=C apt install
>
> This works in all shells, at the cost of being slightly less efficient.
> No, ( setenv var something ; command ) works with csh.
What Greg posted also works, because it's an
invocation of the 'env' command, not csh syntax.
What you posted also works, but it runs the command in a subshell of
csh, so I doubt it gains efficiency over running the command under env.
Nicolas George
Feb 13, 2024, 5:30:06 PMFeb 13
to
Will Mengarini (12024-02-13):
> What Greg posted also works, because it's an
> invocation of the 'env' command, not csh syntax.
Yes. What made Greg's statement false was not the fact that it does not
work but the verb “need”.
> What you posted also works, but it runs the command in a subshell of
> csh, so I doubt it gains efficiency over running the command under env.
env is also executed in a subshell, but unlike what I posted, env will
also require an exec() and probably some dynamic linking.
--
Nicolas George
> * Greg Wooledge <gr...@wooledge.org> [24-02/13=Tu 15:59 -0500]:
> > In csh, you need to use env. Like this:
^^^^
> What Greg posted also works, because it's an
> invocation of the 'env' command, not csh syntax.
work but the verb “need”.
> What you posted also works, but it runs the command in a subshell of
> csh, so I doubt it gains efficiency over running the command under env.
also require an exec() and probably some dynamic linking.
--
Nicolas George
Nicolas George
Feb 13, 2024, 5:50:06 PMFeb 13
to
Gremlin (12024-02-13):
> Oh like debian does?
>
> cat /etc/default/locale
> # File generated by update-locale
> LANG=en_US.UTF-8
> LANGUAGE=en_US.UTF-8
> LC_ALL=en_US.UTF-8
I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?
--
Nicolas George
> Oh like debian does?
>
> cat /etc/default/locale
> # File generated by update-locale
> LANG=en_US.UTF-8
> LANGUAGE=en_US.UTF-8
> LC_ALL=en_US.UTF-8
I do not observe this, even after “sudo dpkg-reconfigure locales”. Can
you explain how you reached this state?
--
Nicolas George
Gremlin
Feb 13, 2024, 5:50:07 PMFeb 13
to
On 2/13/24 16:45, Greg Wooledge wrote:
> On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote:
>> egrep ALL .bashrc
>> LC_ALL=C
>
> This has gone pretty far off the rails, but here we are. Let's address
> this.
>
> DO NOT set LC_ALL in your .bashrc or equivalent files. This is a horrible
> idea. LC_ALL should only be used in single commands as a full-powered
> override, for example when you want to report a bug, and need the output
> to be normalized to the "C" locale.
> On Tue, Feb 13, 2024 at 01:21:20PM -0800, John Conover wrote:
>> egrep ALL .bashrc
>> LC_ALL=C
>
> This has gone pretty far off the rails, but here we are. Let's address
> this.
>
> DO NOT set LC_ALL in your .bashrc or equivalent files. This is a horrible
> idea. LC_ALL should only be used in single commands as a full-powered
> override, for example when you want to report a bug, and need the output
> to be normalized to the "C" locale.
Oh like debian does?
cat /etc/default/locale
# File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
locale
cat /etc/default/locale
# File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
Greg Wooledge
Feb 13, 2024, 6:00:06 PMFeb 13
to
unicorn:~$ cat /etc/default/locale
Gremlin
Feb 13, 2024, 7:40:06 PMFeb 13
to
Upon investigation, I can not determine which package
/etc/default/locale belongs too.
dpkg -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale
dpkg-query -S /etc/default/locale
dpkg-query: no path found matching pattern /etc/default/locale
apt-file search /etc/default/locale
returns nothing
apt-file search locale|grep '/etc/default'
nothing
cruft-ng doesn't find it
This is going no where fast.....
Andy Smith
Feb 13, 2024, 7:50:06 PMFeb 13
to
Hi,
On Tue, Feb 13, 2024 at 07:29:37PM -0500, Gremlin wrote:
> Upon investigation, I can not determine which package
> /etc/default/locale belongs too.
dpkg -S and apt-file will only find files that are actually shipped
in packages. Files that are created or used by maintainer scripts
but not actually shipped by a package will not be found by these
commands.
You can look in all the maintainer scripts to see where it's
mentioned:
$ grep -r /etc/default/locale /var/lib/dpkg/info
which leads me to believe it may be most relevant to the "locales"
package, but this does not enlighten us to how any particular entry
may have been added to that file.
I guess at some point something called update-locale with LC_ALL=C
or something.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
On Tue, Feb 13, 2024 at 07:29:37PM -0500, Gremlin wrote:
> Upon investigation, I can not determine which package
> /etc/default/locale belongs too.
in packages. Files that are created or used by maintainer scripts
but not actually shipped by a package will not be found by these
commands.
You can look in all the maintainer scripts to see where it's
mentioned:
$ grep -r /etc/default/locale /var/lib/dpkg/info
which leads me to believe it may be most relevant to the "locales"
package, but this does not enlighten us to how any particular entry
may have been added to that file.
I guess at some point something called update-locale with LC_ALL=C
or something.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Gremlin
Feb 13, 2024, 8:00:06 PMFeb 13
to
LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC
LANGUAGE=$LOC
Greg Wooledge
Feb 13, 2024, 8:20:05 PMFeb 13
to
On Tue, Feb 13, 2024 at 07:56:46PM -0500, Gremlin wrote:
> Found this in a shell script:
>
> LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC
> LANGUAGE=$LOC
In *what* shell script?
> Found this in a shell script:
>
> LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC
> LANGUAGE=$LOC
Max Nikulin
Feb 13, 2024, 9:30:06 PMFeb 13
to
On 14/02/2024 07:56, Gremlin wrote:
>>> Gremlin (12024-02-13):
LANGUAGE=en_US:en
Its value is a list of languages, not a locale. This variable may affect
messages generated by some applications, especially GUI ones, even when
LC_ALL is set.
>>> Gremlin (12024-02-13):
>>>>
>>>> cat /etc/default/locale
>>>> # File generated by update-locale
>>>> LANG=en_US.UTF-8
>>>> LANGUAGE=en_US.UTF-8
>
>>>> cat /etc/default/locale
>>>> # File generated by update-locale
>>>> LANG=en_US.UTF-8
>>>> LANGUAGE=en_US.UTF-8
>
> Found this in a shell script:
>
> LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC
> LANGUAGE=$LOC
Do not do it for LANGUAGE, it should obey another conventions
>
> LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC
> LANGUAGE=$LOC
LANGUAGE=en_US:en
Its value is a list of languages, not a locale. This variable may affect
messages generated by some applications, especially GUI ones, even when
LC_ALL is set.
Gremlin
Feb 13, 2024, 9:50:07 PMFeb 13
to
This is from a script installed by a package that does a
dpkg-reconfigure locales to set the locale on the machine.
BTW where is LANGUAGE defined in the "standards/conventions"?
Greg Wooledge
Feb 13, 2024, 10:20:05 PMFeb 13
to
On Tue, Feb 13, 2024 at 09:47:52PM -0500, Gremlin wrote:
> This is from a script installed by a package that does a
> dpkg-reconfigure locales to set the locale on the machine.
What package? What script?
> This is from a script installed by a package that does a
> dpkg-reconfigure locales to set the locale on the machine.
> BTW where is LANGUAGE defined in the "standards/conventions"?
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html
Gremlin
Feb 14, 2024, 5:30:05 AMFeb 14
to
On 2/13/24 22:11, Greg Wooledge wrote:
> On Tue, Feb 13, 2024 at 09:47:52PM -0500, Gremlin wrote:
>> This is from a script installed by a package that does a
>> dpkg-reconfigure locales to set the locale on the machine.
>
> What package? What script?
I am working on it with a high rate a speed, should be completed next year.
> On Tue, Feb 13, 2024 at 09:47:52PM -0500, Gremlin wrote:
>> This is from a script installed by a package that does a
>> dpkg-reconfigure locales to set the locale on the machine.
>
> What package? What script?
>
>> BTW where is LANGUAGE defined in the "standards/conventions"?
>
> It's a GNUism.
>
> https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html
>
>
Hindi madali ang maging ako
Greg Wooledge
Feb 14, 2024, 11:20:07 AMFeb 14
to
On Wed, Feb 14, 2024 at 05:11:55PM +0100, Franco Martelli wrote:
> Well, I'll go with env command syntax for shells portability. I was asking
> this because I want to suggest a change to the DDP (Debian Documentation
> Project) members for the releases notes documentation น
>
> The change I want to suggest is to add "env LC_ALL=C" to the "script"
> command:
>
> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> ~/upgrade-bookwormstep.script
That command is already using Bourne family shell syntax (the 2> part)
so you can drop the env. It'll fail in csh regardless. On the other
hand, the env doesn't hurt anything. It's just extra typing.
> Well, I'll go with env command syntax for shells portability. I was asking
> this because I want to suggest a change to the DDP (Debian Documentation
> Project) members for the releases notes documentation น
>
> The change I want to suggest is to add "env LC_ALL=C" to the "script"
> command:
>
> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> ~/upgrade-bookwormstep.script
That command is already using Bourne family shell syntax (the 2> part)
so you can drop the env. It'll fail in csh regardless. On the other
hand, the env doesn't hurt anything. It's just extra typing.
Franco Martelli
Feb 14, 2024, 11:20:07 AMFeb 14
to
Well, I'll go with env command syntax for shells portability. I was
asking this because I want to suggest a change to the DDP (Debian
Documentation Project) members for the releases notes documentation ¹
asking this because I want to suggest a change to the DDP (Debian
The change I want to suggest is to add "env LC_ALL=C" to the "script"
command:
# env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
~/upgrade-bookwormstep.script
English is better then a localized session for debugging purposes.
Thanks to all for the feedback!
¹
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#record-session
--
Franco Martelli
Franco Martelli
Feb 14, 2024, 11:40:07 AMFeb 14
to
On 14/02/24 at 17:15, Greg Wooledge wrote:
>> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
>> ~/upgrade-bookwormstep.script
> That command is already using Bourne family shell syntax (the 2> part)
> so you can drop the env. It'll fail in csh regardless. On the other
> hand, the env doesn't hurt anything. It's just extra typing.
>
Ah! However it's needed for csh users so they are warned, if it's extra
>> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
>> ~/upgrade-bookwormstep.script
> That command is already using Bourne family shell syntax (the 2> part)
> so you can drop the env. It'll fail in csh regardless. On the other
> hand, the env doesn't hurt anything. It's just extra typing.
>
typing it doesn't hurt, thought.
--
Franco Martelli
Greg Wooledge
Feb 14, 2024, 11:50:06 AMFeb 14
to
stdout only, or redirect them both into the same file. It has *nothing*
equivalent to >file1 2>file2.
The usual recommendations for csh users who need to do this are either:
1) Run sh, and then run the command.
2) sh -c 'long command with >file1 2>file2'
Franco Martelli
Feb 14, 2024, 3:50:06 PMFeb 14
to
On 14/02/24 at 17:48, Greg Wooledge wrote:
> On Wed, Feb 14, 2024 at 05:35:59PM +0100, Franco Martelli wrote:
>> On 14/02/24 at 17:15, Greg Wooledge wrote:
>>>> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
>>>> ~/upgrade-bookwormstep.script
>>> That command is already using Bourne family shell syntax (the 2> part)
>>> so you can drop the env. It'll fail in csh regardless. On the other
>>> hand, the env doesn't hurt anything. It's just extra typing.
>>>
>>
>> Ah! However it's needed for csh users so they are warned, if it's extra
>> typing it doesn't hurt, thought.
>
> csh cannot redirect stdout and stderr separately. You can either redirect
> stdout only, or redirect them both into the same file. It has *nothing*
> equivalent to >file1 2>file2.
A new question arise spontaneously: how can csh users run a "script"
> On Wed, Feb 14, 2024 at 05:35:59PM +0100, Franco Martelli wrote:
>> On 14/02/24 at 17:15, Greg Wooledge wrote:
>>>> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
>>>> ~/upgrade-bookwormstep.script
>>> That command is already using Bourne family shell syntax (the 2> part)
>>> so you can drop the env. It'll fail in csh regardless. On the other
>>> hand, the env doesn't hurt anything. It's just extra typing.
>>>
>>
>> Ah! However it's needed for csh users so they are warned, if it's extra
>> typing it doesn't hurt, thought.
>
> csh cannot redirect stdout and stderr separately. You can either redirect
> stdout only, or redirect them both into the same file. It has *nothing*
> equivalent to >file1 2>file2.
saved session using "scriptreplay" command? In the §4.4.1 "Recording the
session" paragraph ¹ I see this syntax:
# scriptreplay ~/upgrade-bookwormstep.time ~/upgrade-bookwormstep.script
That it uses both stderr and stdout saved separately. Maybe they have to
use another syntax or forcibly run a Bourne shell as you wrote below:
>
> The usual recommendations for csh users who need to do this are either:
>
> 1) Run sh, and then run the command.
> 2) sh -c 'long command with >file1 2>file2'
Thanks again
Greg Wooledge
Feb 14, 2024, 4:00:06 PMFeb 14
to
On Wed, Feb 14, 2024 at 09:45:52PM +0100, Franco Martelli wrote:
> A new question arise spontaneously: how can csh users run a "script" saved
> session using "scriptreplay" command? In the ง4.4.1 "Recording the session"
> A new question arise spontaneously: how can csh users run a "script" saved
> paragraph น I see this syntax:
>
> # scriptreplay ~/upgrade-bookwormstep.time ~/upgrade-bookwormstep.script
>
> That it uses both stderr and stdout saved separately. Maybe they have to use
> another syntax or forcibly run a Bourne shell as you wrote below:
The man page says:
> # scriptreplay ~/upgrade-bookwormstep.time ~/upgrade-bookwormstep.script
>
> That it uses both stderr and stdout saved separately. Maybe they have to use
> another syntax or forcibly run a Bourne shell as you wrote below:
-t[file], --timing[=file]
Output timing data to standard error, or to file when given. This
option is deprecated in favour of --log-timing where the file
argument is not optional.
And:
-T, --log-timing file
Log timing information to the file. Two timing file formats are
supported now. The classic format is used when only one stream
(input or output) logging is enabled. The multi-stream format is
used on --log-io or when --log-in and --log-out are used together.
See also --logging-format.
One of these paragraphs should give a solution that avoids needing 2>.
Max Nikulin
Feb 14, 2024, 9:30:06 PMFeb 14
to
On 14/02/2024 23:11, Franco Martelli wrote:
> Well, I'll go with env command syntax for shells portability. I was
> asking this because I want to suggest a change to the DDP (Debian
> Documentation Project) members for the releases notes documentation ¹
>
> Well, I'll go with env command syntax for shells portability. I was
> asking this because I want to suggest a change to the DDP (Debian
> Documentation Project) members for the releases notes documentation ¹
>
> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> ~/upgrade-bookwormstep.script
Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some python
> ~/upgrade-bookwormstep.script
scripts (unrelated to Debian upgrade however) failed trying to log e.g.
non-ascii file paths, etc.
I would reset LANGUAGE as well otherwise some programs may use localized
messages.
Finally, some users might have LC_ALL (despite it is not recommended) or
LANGUAGE set in a file like ~/.bashrc. That is why the following
approach may be more reliable. Run commands within the "script" session
LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
with a note concerning csh. To affect messages generated by shell
itself, "export" is separated from setting of the variables.
Franco Martelli
Feb 15, 2024, 3:20:06 PMFeb 15
to
Thanks Max,
On 15/02/24 at 03:28, Max Nikulin wrote:
>> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
>> ~/upgrade-bookwormstep.script
>
> Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some python
> scripts (unrelated to Debian upgrade however) failed trying to log e.g.
> non-ascii file paths, etc.
>
> I would reset LANGUAGE as well otherwise some programs may use localized
> messages.
>
> Finally, some users might have LC_ALL (despite it is not recommended) or
> LANGUAGE set in a file like ~/.bashrc. That is why the following
> approach may be more reliable. Run commands within the "script" session
>
> LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
>
> with a note concerning csh. To affect messages generated by shell
> itself, "export" is separated from setting of the variables.
Doesn't LC_ALL=C setting override LANG or LANGUAGE settings? On my
system I have:
~$ env | grep LANG
LANGUAGE=
LANG=it_IT.UTF-8
and LC_ALL=C override the LANG setting when used inline of the command.
This approach is to cover all cases, my goal is to do apt/apt-get
commands output in English when they are executed into a "script"
session. Thank to Greg's contribute I think I've reached it:
> On 14/02/24 at 21:55, Greg Wooledge wrote:
>> The man page says:
>>
>> -t[file], --timing[=file]
>> Output timing data to standard error, or to file when given. This
>> option is deprecated in favour of --log-timing where the file
>> argument is not optional.
>>
>> And:
>>
>> -T, --log-timing file
>> Log timing information to the file. Two timing file formats are
>> supported now. The classic format is used when only one stream
>> (input or output) logging is enabled. The multi-stream format is
>> used on --log-io or when --log-in and --log-out are used together.
>> See also --logging-format.
>>
>> One of these paragraphs should give a solution that avoids needing 2>.
The following "script" command syntax should work on all shells (tested
only in Bash):
# env LC_ALL=C script -T ~/upgrade-bookwormstep.time -a
~/upgrade-bookwormstep.script
--
Franco Martelli
On 15/02/24 at 03:28, Max Nikulin wrote:
>> # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
>> ~/upgrade-bookwormstep.script
>
> Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some python
> scripts (unrelated to Debian upgrade however) failed trying to log e.g.
> non-ascii file paths, etc.
>
> I would reset LANGUAGE as well otherwise some programs may use localized
> messages.
>
> Finally, some users might have LC_ALL (despite it is not recommended) or
> LANGUAGE set in a file like ~/.bashrc. That is why the following
> approach may be more reliable. Run commands within the "script" session
>
> LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
>
> with a note concerning csh. To affect messages generated by shell
> itself, "export" is separated from setting of the variables.
system I have:
~$ env | grep LANG
LANGUAGE=
LANG=it_IT.UTF-8
and LC_ALL=C override the LANG setting when used inline of the command.
This approach is to cover all cases, my goal is to do apt/apt-get
commands output in English when they are executed into a "script"
session. Thank to Greg's contribute I think I've reached it:
> On 14/02/24 at 21:55, Greg Wooledge wrote:
>> The man page says:
>>
>> -t[file], --timing[=file]
>> Output timing data to standard error, or to file when given. This
>> option is deprecated in favour of --log-timing where the file
>> argument is not optional.
>>
>> And:
>>
>> -T, --log-timing file
>> Log timing information to the file. Two timing file formats are
>> supported now. The classic format is used when only one stream
>> (input or output) logging is enabled. The multi-stream format is
>> used on --log-io or when --log-in and --log-out are used together.
>> See also --logging-format.
>>
>> One of these paragraphs should give a solution that avoids needing 2>.
only in Bash):
# env LC_ALL=C script -T ~/upgrade-bookwormstep.time -a
~/upgrade-bookwormstep.script
--
Franco Martelli
Max Nikulin
Feb 15, 2024, 9:10:06 PMFeb 15
to
On 16/02/2024 03:17, Franco Martelli wrote:
> On 15/02/24 at 03:28, Max Nikulin wrote:
>>
>> LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
>
> On 15/02/24 at 03:28, Max Nikulin wrote:
>>
>> LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
>
> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings?
Sorry, my bad. Of course
LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
> and LC_ALL=C override the LANG setting when used inline of the command.
LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr
> # env LC_ALL=C script -T ~/upgrade-bookwormstep.time -a
> ~/upgrade-bookwormstep.script
script session.
David Wright
Feb 15, 2024, 9:40:06 PMFeb 15
to
On Thu 15 Feb 2024 at 21:17:44 (+0100), Franco Martelli wrote:
> On 15/02/24 at 03:28, Max Nikulin wrote:
> > > # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> > > ~/upgrade-bookwormstep.script
> >
> > Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some
> > python scripts (unrelated to Debian upgrade however) failed trying
> > to log e.g. non-ascii file paths, etc.
> >
> > I would reset LANGUAGE as well otherwise some programs may use
> > localized messages.
> >
> > Finally, some users might have LC_ALL (despite it is not
> > recommended) or LANGUAGE set in a file like ~/.bashrc. That is why
> > the following approach may be more reliable. Run commands within
> > the "script" session
> >
> > LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
> >
> > with a note concerning csh. To affect messages generated by shell
> > itself, "export" is separated from setting of the variables.
>
> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings? On my
> system I have:
>
> ~$ env | grep LANG
> LANGUAGE=
> LANG=it_IT.UTF-8
BTW, you can also print locale information with:
> On 15/02/24 at 03:28, Max Nikulin wrote:
> > > # env LC_ALL=C script -t 2>~/upgrade-bookwormstep.time -a
> > > ~/upgrade-bookwormstep.script
> >
> > Perhaps LC_ALL=C.UTF-8 is safer. At least several years ago some
> > python scripts (unrelated to Debian upgrade however) failed trying
> > to log e.g. non-ascii file paths, etc.
> >
> > I would reset LANGUAGE as well otherwise some programs may use
> > localized messages.
> >
> > Finally, some users might have LC_ALL (despite it is not
> > recommended) or LANGUAGE set in a file like ~/.bashrc. That is why
> > the following approach may be more reliable. Run commands within
> > the "script" session
> >
> > LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
> >
> > with a note concerning csh. To affect messages generated by shell
> > itself, "export" is separated from setting of the variables.
>
> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings? On my
> system I have:
>
> ~$ env | grep LANG
> LANGUAGE=
> LANG=it_IT.UTF-8
$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=
$
> and LC_ALL=C override the LANG setting when used inline of the
> command. This approach is to cover all cases, my goal is to do
> apt/apt-get commands output in English when they are executed into a
> "script" session.
but LC_ALL=C.UTF-8 will not:
$ LC_ALL=C.UTF-8 LANGUAGE=it LANG=it_IT.UTF-8 aptitude why firefox-esr
i firefox-esr-l10n-en-gb Dipende firefox-esr (< 115.7.0esr-1~deb11u1.1~)
$ LC_ALL=C LANGUAGE=it LANG=it_IT.UTF-8 aptitude why firefox-esr
i firefox-esr-l10n-en-gb Depends firefox-esr (< 115.7.0esr-1~deb11u1.1~)
$
Cheers,
David.
Max Nikulin
Feb 15, 2024, 10:10:06 PMFeb 15
to
On 16/02/2024 09:34, David Wright wrote:
>
> Yes, LC_ALL=C will override all the locale variables,
> but LC_ALL=C.UTF-8 will not:
It is documented in
>
> Yes, LC_ALL=C will override all the locale variables,
> but LC_ALL=C.UTF-8 will not:
2.3.3 Specifying a Priority List of Languages
(info "(gettext) The LANGUAGE variable")
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html
however you may still prefer
LC_ALL=C.UTF-8 LANGUAGE=
due to
touch /tmp/it/è
LC_ALL=C.UTF-8 ls /tmp/it/
è
LC_ALL=C ls /tmp/it/
''$'\303\250'
Teemu Likonen
Feb 16, 2024, 2:20:07 AMFeb 16
to
* 2024-02-15 21:17:44+0100, Franco Martelli wrote:
> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings?
LC_ALL overrides LC_* variables. It's easy to test:
> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings?
$ locale
LANG=fi_FI.UTF-8
LANGUAGE=fi
LC_CTYPE="fi_FI.UTF-8"
LC_NUMERIC="fi_FI.UTF-8"
LC_TIME="fi_FI.UTF-8"
LC_COLLATE="fi_FI.UTF-8"
LC_MONETARY="fi_FI.UTF-8"
LC_MESSAGES=C
LC_PAPER="fi_FI.UTF-8"
LC_NAME="fi_FI.UTF-8"
LC_ADDRESS="fi_FI.UTF-8"
LC_TELEPHONE="fi_FI.UTF-8"
LC_MEASUREMENT="fi_FI.UTF-8"
LC_IDENTIFICATION="fi_FI.UTF-8"
$ LC_ALL=C locale
LANG=fi_FI.UTF-8
LANGUAGE=fi
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_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
$ LC_ALL=C.UTF-8 locale
LANG=fi_FI.UTF-8
LANGUAGE=fi
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=C.UTF-8
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
In my opinion it's often too much to set LC_ALL=C because it changes
charset to ASCII (LC_CTYPE).
To change programs' output messages to English LC_MESSAGES=C is often
enough. Sometimes LC_TIME and LC_NUMERIC are required too.
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
Greg Wooledge
Feb 16, 2024, 7:20:06 AMFeb 16
to
On Fri, Feb 16, 2024 at 09:13:40AM +0200, Teemu Likonen wrote:
> In my opinion it's often too much to set LC_ALL=C because it changes
> charset to ASCII (LC_CTYPE).
It depends on what you're doing, of course. If the purpose is to
> In my opinion it's often too much to set LC_ALL=C because it changes
> charset to ASCII (LC_CTYPE).
normalize error messages so that you can report your issue to an
English-only mailing list, and if LC_ALL=C doesn't mangle the
output beyond recognition, then it might be good enough.
The OP of this thread seemed to have a goal of altering Debian
documentation to have *everyone* performing a dist-upgrade run
their dist-upgrade sessions under LC_ALL=C for reasons that I
can't remember (or which weren't stated). I'm uncertain what the
larger goal is there -- many of these users would probably have
difficulty reading their own session logs afterward.
Franco Martelli
Feb 16, 2024, 11:40:06 AMFeb 16
to
Franco Martelli
Feb 16, 2024, 11:40:06 AMFeb 16
to
On 16/02/24 at 03:03, Max Nikulin wrote:
> On 16/02/2024 03:17, Franco Martelli wrote:
>> On 15/02/24 at 03:28, Max Nikulin wrote:
>>>
>>> LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
>>
>> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings?
>
> Sorry, my bad. Of course
>
> LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
>
>> and LC_ALL=C override the LANG setting when used inline of the command.
>
>
> LC_ALL does not override LANGUAGE. Try e.g.
>
> LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr
here seems to override, tested twice with "it" and "it_IT.UTF-8":
> On 16/02/2024 03:17, Franco Martelli wrote:
>> On 15/02/24 at 03:28, Max Nikulin wrote:
>>>
>>> LANG=C.UTF-8; LANGUAGE=; export LANG LANGUAGE
>>
>> Doesn't LC_ALL=C setting override LANG or LANGUAGE settings?
>
> Sorry, my bad. Of course
>
> LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
>
>> and LC_ALL=C override the LANG setting when used inline of the command.
>
>
> LC_ALL does not override LANGUAGE. Try e.g.
>
> LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr
~# env LC_ALL=C LANGUAGE=it script -T ~/test.time -a ~/test.script
Script started, output log file is '/root/test.script', timing file is
'/root/test.time'.
root@itek:~# date
Fri Feb 16 15:27:06 CET 2024
root@itek:~# apt install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
root@itek:~#
exit
Script done.
root@itek:~# env LC_ALL=C LANGUAGE=it_IT.UTF-8 script -T ~/test.time -a
~/test.script
Script started, output log file is '/root/test.script', timing file is
'/root/test.time'.
root@itek:~# date
Fri Feb 16 15:28:42 CET 2024
root@itek:~# apt install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
root@itek:~#
exit
Script done.
and with "export LANGUAGE=it" defined in .bashrc LC_ALL=C override the same:
root@itek:~# env LC_ALL=C script -T ~/test.time -a ~/test.script
Script started, output log file is '/root/test.script', timing file is
'/root/test.time'.
root@itek:~# date
Fri Feb 16 15:39:05 CET 2024
root@itek:~# apt install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
root@itek:~#
exit
Script done.
>
>> # env LC_ALL=C script -T ~/upgrade-bookwormstep.time -a
>> ~/upgrade-bookwormstep.script
>
> Try to add "export LC_ALL=it_IT.UTF-8" to .bashrc and e.g."date" in the
> script session.
session, however users that have set LC_ALL variable into .bashrc I
suppose already know what are they doing.
--
Franco Martelli
Greg Wooledge
Feb 16, 2024, 11:50:07 AMFeb 16
to
On Fri, Feb 16, 2024 at 05:35:04PM +0100, Franco Martelli wrote:
> It was stated here:
> https://lists.debian.org/debian-user/2024/02/msg00592.html
> It was stated here:
> https://lists.debian.org/debian-user/2024/02/msg00592.html
"I think that a recorded session with the output of the commands in
English is better then a localized session for debugging purposes."
I have trouble following your reasoning there. Do you mean that you
English is better then a localized session for debugging purposes."
expect they'll hand over the logs to *someone else* to debug, instead
of reading it themselves? I mean, that may be true, but you certainly
didn't state it. That leaves me needing to guess.
If my guess is correct, then I don't support the plan to modify the
Debian documentation to suggest that everyone log their dist-upgrades
in English "because if something goes wrong you will probably ask for
help from an English speaker". There are way too many layers of
assumptions there.
On Fri, Feb 16, 2024 at 05:35:11PM +0100, Franco Martelli wrote:
> however users that have set LC_ALL variable into .bashrc I suppose already
> know what are they doing.
to...@tuxteam.de
Feb 16, 2024, 1:30:06 PMFeb 16
to
On Fri, Feb 16, 2024 at 11:44:21AM -0500, Greg Wooledge wrote:
> On Fri, Feb 16, 2024 at 05:35:04PM +0100, Franco Martelli wrote:
> > It was stated here:
> > https://lists.debian.org/debian-user/2024/02/msg00592.html
>
> "I think that a recorded session with the output of the commands in
> English is better then a localized session for debugging purposes."
>
> I have trouble following your reasoning there. Do you mean that you
> expect they'll hand over the logs to *someone else* to debug, instead
> of reading it themselves? I mean, that may be true, but you certainly
> didn't state it. That leaves me needing to guess.
There's also looking up errors on a search engine. English texts do
> On Fri, Feb 16, 2024 at 05:35:04PM +0100, Franco Martelli wrote:
> > It was stated here:
> > https://lists.debian.org/debian-user/2024/02/msg00592.html
>
> "I think that a recorded session with the output of the commands in
> English is better then a localized session for debugging purposes."
>
> I have trouble following your reasoning there. Do you mean that you
> expect they'll hand over the logs to *someone else* to debug, instead
> of reading it themselves? I mean, that may be true, but you certainly
> didn't state it. That leaves me needing to guess.
have a higher probability of a meaningful hit.
But yes, it's complicated, to say the least (a case in point: my main
(not my native) language is currently German, but I vastly prefer
error messages in English).
Cheers
--
t
Franco Martelli
Feb 16, 2024, 4:30:05 PMFeb 16
to
On 16/02/24 at 17:44, Greg Wooledge wrote:
> If my guess is correct, then I don't support the plan to modify the
> Debian documentation to suggest that everyone log their dist-upgrades
> in English "because if something goes wrong you will probably ask for
> help from an English speaker". There are way too many layers of
> assumptions there.
> If my guess is correct, then I don't support the plan to modify the
> Debian documentation to suggest that everyone log their dist-upgrades
> in English "because if something goes wrong you will probably ask for
> help from an English speaker". There are way too many layers of
> assumptions there.
No it wasn't for this argument that I wrote:
> "I think that a recorded session with the output of the commands in
> English is better then a localized session for debugging purposes."
In the paragraph in question ¹ I read:
> "I think that a recorded session with the output of the commands in
> English is better then a localized session for debugging purposes."
"It is strongly recommended that you use the /usr/bin/script program to
record a transcript of the upgrade session. Then if a problem occurs,
you will have a log of what happened, and if needed, can provide exact
information in a bug report. To start the recording, type:"
Therefore I ran "script" session to upgrade to stable 12.5, then I saw
that the output of "apt" was localized to my native language. So I
thought: How can I provide exact information in a bug report if I've
only localized messages?
For this reason I've asked for feedback here before to propose a change
to the syntax to the "script" command that IMHO it'd be:
# env LC_ALL=C.UTF-8 script -T ~/upgrade-bookwormstep.time -a
~/upgrade-bookwormstep.script
or at the place of LC_ALL to use instead LC_MESSAGES as Teemu wrote:
On 16/02/24 at 08:13, Teemu Likonen wrote:
> To change programs' output messages to English LC_MESSAGES=C is often
> enough. Sometimes LC_TIME and LC_NUMERIC are required too.
From the manual page of "script" command the -t option is deprecated in
favor of -T and the above command has the advantage to be executable in
all shells (thank to your feedback). A change is required however and
the command proposed seems to me an improvement.
>
> On Fri, Feb 16, 2024 at 05:35:11PM +0100, Franco Martelli wrote:
>> however users that have set LC_ALL variable into .bashrc I suppose already
>> know what are they doing.
>
> No. No, they do not. They may *think* they do. They do not.
>
Max Nikulin
Feb 16, 2024, 10:20:06 PMFeb 16
to
On 16/02/2024 23:35, Franco Martelli wrote:
> On 16/02/24 at 03:03, Max Nikulin wrote:
>> LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr
>
> here seems to override, tested twice with "it" and "it_IT.UTF-8":
>
> ~# env LC_ALL=C LANGUAGE=it script -T ~/test.time -a ~/test.script
You tested with LC_ALL=C, not with LC_ALL=C.UTF-8. It has been discussed
> On 16/02/24 at 03:03, Max Nikulin wrote:
>> LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr
>
> here seems to override, tested twice with "it" and "it_IT.UTF-8":
>
> ~# env LC_ALL=C LANGUAGE=it script -T ~/test.time -a ~/test.script
that behavior of gettext in respect to LANGUAGE is different.
I am against "C" locale in Debian official docs since it may mangle
output. I have posted it already:
LC_ALL=C ls /tmp/it/
''$'\303\250'
è
> root@itek:~# env LC_ALL=C LANGUAGE=it_IT.UTF-8 script -T ~/test.time -a
> ~/test.script
LANG or LC_*. LANGUAGE can be it:en_US:en, while this value is invalid
for LC_ALL. Do not confuse these variables.
>> Try to add "export LC_ALL=it_IT.UTF-8" to .bashrc and e.g."date" in
>> the script session.
>
> Yes, the messages are localized to it_IT.UTF-8 into the "script"
> session, however users that have set LC_ALL variable into .bashrc I
> suppose already know what are they doing.
My colleague was bitten by LC_ALL. Is was a surprise when a database
started to use "," instead of "." as decimal separator and it took
enough time to find what caused drastic lost of precision. LC_ALL was
set by the system administrator in ~/.bashrc.
I like the idea to *suggest* people to use English locale for upgrades
if they are comfortable with it. It will help for searching web and
during discussions. However I believe that a UTF-8 locale is safer and
better nowadays. I hope, there is no mistakes any more:
LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
unsure if locale of "script" command can be an issue.
0 new messages