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 2 of 2 — ← Prev page 1 [2]

#267452

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

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'

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

#267457

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

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

    $ 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

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

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

#267462

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

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

#267482

On 16/02/24 at 13:17, Greg Wooledge wrote:
> 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
> 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.
> 

It was stated here:
https://lists.debian.org/debian-user/2024/02/msg00592.html

-- 
Franco Martelli

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

#267372

Franco Martelli (12024-02-13):
> 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
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

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

#267376

John Conover (12024-02-13):
> > 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
the command”.

-- 
  Nicolas George

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

#267377

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.:
>
.
.
.
> 
> So the question is: does anybody know if this syntax works on all shells 
> other than bash? csh, korn, dash, zsh …
> 

Hi Franco.

    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, conover@panix.com, http://www.johncon.com/

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

#267379

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.

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

#267382

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

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

#267385

On Tue, Feb 13, 2024 at 11:48:04PM +0100, Nicolas George wrote:
> 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?

Indeed.  That is NOT normal.

unicorn:~$ cat /etc/default/locale
#  File generated by update-locale
LANG=en_US.UTF-8

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

#267386

On 2/13/24 17:48, Nicolas George wrote:
> 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?

I will try:

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

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

#267387

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

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

#267388

On 2/13/24 19:29, Gremlin wrote:
> On 2/13/24 17:48, Nicolas George wrote:
>> 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?
> 
> I will try:
> 
> 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.....
> 
> 

Found this in a shell script:

LC_ALL=$LOC LANG=$LOC LANGUAGE=$LOC update-locale LANG=$LOC LC_ALL=$LOC 
LANGUAGE=$LOC

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

#267389

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?

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

#267391

On 14/02/2024 07:56, Gremlin wrote:
>>> Gremlin (12024-02-13):
>>>>
>>>> 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

     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.

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

#267392

On 2/13/24 21:22, Max Nikulin wrote:
> On 14/02/2024 07:56, Gremlin wrote:
>>>> Gremlin (12024-02-13):
>>>>>
>>>>> 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
> 
>      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.
> 
> 
> 


I get your point but I didn't do it, git blame others.

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

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

#267393

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

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

#267399

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.

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

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

#267384

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.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web