Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #267370 > unrolled thread

Does "LC_ALL=C" work on all shells?

Back to article view | Back to linux.debian.user

Contents

  Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-13 21:50 +0100
    Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-13 22:00 +0100
      Re: Does "LC_ALL=C" work on all shells? Nicolas George <george@nsup.org> - 2024-02-13 22:10 +0100
        Re: Does "LC_ALL=C" work on all shells? Will Mengarini <seldon@eskimo.com> - 2024-02-13 23:00 +0100
          Re: Does "LC_ALL=C" work on all shells? Nicolas George <george@nsup.org> - 2024-02-13 23:30 +0100
            Re: Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-14 17:20 +0100
              Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-14 17:20 +0100
                Re: Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-14 17:40 +0100
                  Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-14 17:50 +0100
                    Re: Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-14 21:50 +0100
                      Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-14 22:00 +0100
              Re: Does "LC_ALL=C" work on all shells? Max Nikulin <manikulin@gmail.com> - 2024-02-15 03:30 +0100
                Re: Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-15 21:20 +0100
                  Re: Does "LC_ALL=C" work on all shells? Max Nikulin <manikulin@gmail.com> - 2024-02-16 03:10 +0100
                    Re: Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-16 17:40 +0100
                      Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-16 17:50 +0100
                        Re: Does "LC_ALL=C" work on all shells? <tomas@tuxteam.de> - 2024-02-16 19:30 +0100
                        Re: Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-16 22:30 +0100
                      Re: Does "LC_ALL=C" work on all shells? Max Nikulin <manikulin@gmail.com> - 2024-02-17 04:20 +0100
                  Re: Does "LC_ALL=C" work on all shells? David Wright <deblis@lionunicorn.co.uk> - 2024-02-16 03:40 +0100
                    Re: Does "LC_ALL=C" work on all shells? Max Nikulin <manikulin@gmail.com> - 2024-02-16 04:10 +0100
                  Re: Does "LC_ALL=C" work on all shells? Teemu Likonen <tlikonen@iki.fi> - 2024-02-16 08:20 +0100
                    Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-16 13:20 +0100
                      Re: Does "LC_ALL=C" work on all shells? Franco Martelli <martellif67@gmail.com> - 2024-02-16 17:40 +0100
    Re: Does "LC_ALL=C" work on all shells? Nicolas George <george@nsup.org> - 2024-02-13 22:00 +0100
    Re: Does "LC_ALL=C" work on all shells? Nicolas George <george@nsup.org> - 2024-02-13 22:30 +0100
    Re: Does "LC_ALL=C" work on all shells? conover@panix.com (John Conover) - 2024-02-13 22:30 +0100
      Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-13 22:50 +0100
        Re: Does "LC_ALL=C" work on all shells? Nicolas George <george@nsup.org> - 2024-02-13 23:50 +0100
          Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-14 00:00 +0100
          Re: Does "LC_ALL=C" work on all shells? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-14 01:40 +0100
            Re: Does "LC_ALL=C" work on all shells? Andy Smith <andy@strugglers.net> - 2024-02-14 01:50 +0100
            Re: Does "LC_ALL=C" work on all shells? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-14 02:00 +0100
              Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-14 02:20 +0100
              Re: Does "LC_ALL=C" work on all shells? Max Nikulin <manikulin@gmail.com> - 2024-02-14 03:30 +0100
                Re: Does "LC_ALL=C" work on all shells? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-14 03:50 +0100
                  Re: Does "LC_ALL=C" work on all shells? Greg Wooledge <greg@wooledge.org> - 2024-02-14 04:20 +0100
                    Re: Does "LC_ALL=C" work on all shells? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-14 11:30 +0100
        Re: Does "LC_ALL=C" work on all shells? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-13 23:50 +0100

Page 1 of 2  [1] 2  Next page →

#267370 — Does "LC_ALL=C" work on all shells?

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

[toc] | [next] | [standalone]

#267371

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.

[toc] | [prev] | [next] | [standalone]

#267373

Greg Wooledge (12024-02-13):
> 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.

>     % 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

[toc] | [prev] | [next] | [standalone]

#267380

> 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 ...

* Greg Wooledge <greg@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 <george@nsup.org> [24-02/13=Tu 22:04 +0100]:
> 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.

[toc] | [prev] | [next] | [standalone]

#267381

Will Mengarini (12024-02-13):
> * Greg Wooledge <greg@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.

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

[toc] | [prev] | [next] | [standalone]

#267400

On 13/02/24 at 23:23, Nicolas George wrote:
> Will Mengarini (12024-02-13):
>> * Greg Wooledge <greg@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.
> 
> 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.
> 

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

I think that a recorded session with the output of the commands in 
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

[toc] | [prev] | [next] | [standalone]

#267401

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.

[toc] | [prev] | [next] | [standalone]

#267402

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.

-- 
Franco Martelli

[toc] | [prev] | [next] | [standalone]

#267403

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.

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'

[toc] | [prev] | [next] | [standalone]

#267406

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" 
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'

Then run env command at the beginning it is useless.

Thanks again

¹ 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#record-session
-- 
Franco Martelli

[toc] | [prev] | [next] | [standalone]

#267407

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"
> 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:

       -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>.

[toc] | [prev] | [next] | [standalone]

#267414

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 ¹
> 
> # 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.

[toc] | [prev] | [next] | [standalone]

#267439

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

[toc] | [prev] | [next] | [standalone]

#267449

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 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.

[toc] | [prev] | [next] | [standalone]

#267481

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":

~# 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.

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.

-- 
Franco Martelli

[toc] | [prev] | [next] | [standalone]

#267484

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.

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.

No.  No, they do not.  They may *think* they do.  They do not.

[toc] | [prev] | [next] | [standalone]

#267488

[Multipart message — attachments visible in raw view] — view raw

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
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

[toc] | [prev] | [next] | [standalone]

#267507

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.

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:

"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.

but it seems may have drawbacks if other variables are involved.
 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.
> 
Ahah OK they do not.


¹ 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#record-session
-- 
Franco Martelli

[toc] | [prev] | [next] | [standalone]

#267519

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 
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'

LC_ALL=C.UTF-8 ls /tmp/it/
è

> root@itek:~# env LC_ALL=C LANGUAGE=it_IT.UTF-8 script -T ~/test.time -a 
> ~/test.script

Again, LANGUAGE value is a list of *languages*, not a locale like for 
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.

They just noticed that such variable exists and added to their configs. 
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

or its equivalent for user shell executed inside "script" session. I am 
unsure if locale of "script" command can be an issue.

[toc] | [prev] | [next] | [standalone]

#267450

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:

  $ 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.

Yes, LC_ALL=C will override all the locale variables,
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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web