1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • What sets LC_TIME?

    From Anssi Saari@21:1/5 to All on Fri Feb 16 09:30:01 2024
    With the recent LC_ALL thread, I noticed I have LC_TIME set by
    mysterious means on at least two headless systems, for example:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=
    LC_CTYPE=en_US.utf8
    LC_NUMERIC=en_US.utf8
    LC_TIME=en_DK.utf8
    LC_COLLATE=en_US.utf8
    LC_MONETARY=en_US.utf8
    LC_MESSAGES=en_US.utf8
    LC_PAPER=en_US.utf8
    LC_NAME=en_US.utf8
    LC_ADDRESS=en_US.utf8
    LC_TELEPHONE=en_US.utf8
    LC_MEASUREMENT=en_US.utf8
    LC_IDENTIFICATION=en_US.utf8
    LC_ALL=

    LC_TIME ends up with en_DK.utf8. It's what I usually want so I've
    probably set this up and possibly I did it in the Debian installer but
    where does it come from? /etc/default/locale has just LANG=en_US.UTF-8

    find /etc /home/as -type f -print0 -follow|xargs -0 grep -e LC_TIME -e en_DK

    does find some matches, in /etc/locale.gen as expected and in some
    binary files but not in any relevant config file. Come to think of it,
    is this actually hidden inside the initrd somehow?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Anssi Saari on Fri Feb 16 13:30:01 2024
    On Fri, Feb 16, 2024 at 10:24:07AM +0200, Anssi Saari wrote:
    With the recent LC_ALL thread, I noticed I have LC_TIME set by
    mysterious means on at least two headless systems, for example:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=
    LC_CTYPE=en_US.utf8
    LC_NUMERIC=en_US.utf8
    LC_TIME=en_DK.utf8
    LC_COLLATE=en_US.utf8
    LC_MONETARY=en_US.utf8
    LC_MESSAGES=en_US.utf8
    LC_PAPER=en_US.utf8
    LC_NAME=en_US.utf8
    LC_ADDRESS=en_US.utf8
    LC_TELEPHONE=en_US.utf8
    LC_MEASUREMENT=en_US.utf8
    LC_IDENTIFICATION=en_US.utf8
    LC_ALL=

    This is *extremely* abnormal locale output. Here's mine:

    unicorn:~$ locale
    LANG=en_US.utf8
    LANGUAGE=
    LC_CTYPE="en_US.utf8"
    LC_NUMERIC="en_US.utf8"
    LC_TIME=C
    LC_COLLATE="en_US.utf8"
    LC_MONETARY="en_US.utf8"
    LC_MESSAGES="en_US.utf8"
    LC_PAPER="en_US.utf8"
    LC_NAME="en_US.utf8"
    LC_ADDRESS="en_US.utf8"
    LC_TELEPHONE="en_US.utf8"
    LC_MEASUREMENT="en_US.utf8"
    LC_IDENTIFICATION="en_US.utf8"
    LC_ALL=

    Do you see what's different? The double quotes are meaningful here.
    A value that's printed in double quotes is not actually set -- it's
    deduced from LANG. In my output, the only values that are actually
    set are LANG and LC_TIME.

    In yours, *every* variable is set (except LANGUAGE and LC_ALL).

    LC_TIME ends up with en_DK.utf8. It's what I usually want so I've
    probably set this up and possibly I did it in the Debian installer but
    where does it come from? /etc/default/locale has just LANG=en_US.UTF-8

    find /etc /home/as -type f -print0 -follow|xargs -0 grep -e LC_TIME -e en_DK

    does find some matches, in /etc/locale.gen as expected and in some
    binary files but not in any relevant config file. Come to think of it,
    is this actually hidden inside the initrd somehow?

    I can't imagine how the initrd would be related.

    My first suspicion would be your desktop environment, if you're running
    one. Who knows what those things do.

    If you login on a text console (Ctrl-Alt-F2 for example), do you still
    get these same locale values? How about "ssh localhost" (if an ssh
    server is installed)? If those differ from what you see in your desktop environment, then it's a strong indicator the DE is doing something.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anssi Saari@21:1/5 to Greg Wooledge on Fri Feb 16 14:40:01 2024
    Greg Wooledge <greg@wooledge.org> writes:

    On Fri, Feb 16, 2024 at 10:24:07AM +0200, Anssi Saari wrote:
    With the recent LC_ALL thread, I noticed I have LC_TIME set by
    mysterious means on at least two headless systems, for example:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=
    LC_CTYPE=en_US.utf8
    LC_NUMERIC=en_US.utf8
    LC_TIME=en_DK.utf8
    LC_COLLATE=en_US.utf8
    LC_MONETARY=en_US.utf8
    LC_MESSAGES=en_US.utf8
    LC_PAPER=en_US.utf8
    LC_NAME=en_US.utf8
    LC_ADDRESS=en_US.utf8
    LC_TELEPHONE=en_US.utf8
    LC_MEASUREMENT=en_US.utf8
    LC_IDENTIFICATION=en_US.utf8
    LC_ALL=

    This is *extremely* abnormal locale output. Here's mine:

    Yah. It was ssh passing through all that. On serial console, locale
    settings are as expected:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    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=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Anssi Saari on Fri Feb 16 15:20:01 2024
    On Fri, Feb 16, 2024 at 03:34:12PM +0200, Anssi Saari wrote:
    Yah. It was ssh passing through all that. On serial console, locale
    settings are as expected:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LC_CTYPE="en_US.UTF-8"
    LC_NUMERIC="en_US.UTF-8"
    LC_TIME="en_US.UTF-8"
    [...]

    Well then, that just changes the mystery from "happens on the Debian
    system I ssh into" to "happens on my ssh client". For some reason,
    your ssh client has all of those LC_* variables set in its environment,
    which is still quite unusual.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to Greg Wooledge on Fri Feb 16 18:20:01 2024
    On Fri 16 Feb 2024 at 09:12:24 (-0500), Greg Wooledge wrote:
    On Fri, Feb 16, 2024 at 03:34:12PM +0200, Anssi Saari wrote:
    Yah. It was ssh passing through all that. On serial console, locale settings are as expected:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LC_CTYPE="en_US.UTF-8"
    LC_NUMERIC="en_US.UTF-8"
    LC_TIME="en_US.UTF-8"
    [...]

    Well then, that just changes the mystery from "happens on the Debian
    system I ssh into" to "happens on my ssh client". For some reason,
    your ssh client has all of those LC_* variables set in its environment,
    which is still quite unusual.

    Could something weird here do that?

    $ grep LC /etc/ssh/*g
    /etc/ssh/ssh_config: SendEnv LANG LC_*
    /etc/ssh/sshd_config:AcceptEnv LANG LC_*
    $

    Perhaps the OP's also sets SetEnv … in the client's config?

    Cheers,
    David.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to David Wright on Fri Feb 16 22:30:01 2024
    On Fri, Feb 16, 2024 at 11:11:09AM -0600, David Wright wrote:
    On Fri 16 Feb 2024 at 09:12:24 (-0500), Greg Wooledge wrote:
    On Fri, Feb 16, 2024 at 03:34:12PM +0200, Anssi Saari wrote:
    Yah. It was ssh passing through all that. On serial console, locale settings are as expected:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LC_CTYPE="en_US.UTF-8"
    LC_NUMERIC="en_US.UTF-8"
    LC_TIME="en_US.UTF-8"
    [...]

    Well then, that just changes the mystery from "happens on the Debian
    system I ssh into" to "happens on my ssh client". For some reason,
    your ssh client has all of those LC_* variables set in its environment, which is still quite unusual.

    Could something weird here do that?

    $ grep LC /etc/ssh/*g
    /etc/ssh/ssh_config: SendEnv LANG LC_*
    /etc/ssh/sshd_config:AcceptEnv LANG LC_*
    $

    That's all normal and expected.

    What's odd is that client *actually has* LC_NUMERIC and so on set in
    its environment. Which... is not a problem if they're all set to the
    correct values. It's weird, but not wrong. The problem for the OP was
    that one of the values was not set correctly, or at least not as
    expected.

    At this point we have no idea whether the ssh client is even a Unix/Linux system. It could be anything. It could be a literal toaster.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to Greg Wooledge on Sat Feb 17 00:20:02 2024
    On Fri 16 Feb 2024 at 16:25:05 (-0500), Greg Wooledge wrote:
    On Fri, Feb 16, 2024 at 11:11:09AM -0600, David Wright wrote:
    On Fri 16 Feb 2024 at 09:12:24 (-0500), Greg Wooledge wrote:
    On Fri, Feb 16, 2024 at 03:34:12PM +0200, Anssi Saari wrote:
    Yah. It was ssh passing through all that. On serial console, locale settings are as expected:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LC_CTYPE="en_US.UTF-8"
    LC_NUMERIC="en_US.UTF-8"
    LC_TIME="en_US.UTF-8"
    [...]

    Well then, that just changes the mystery from "happens on the Debian system I ssh into" to "happens on my ssh client". For some reason,
    your ssh client has all of those LC_* variables set in its environment, which is still quite unusual.

    Could something weird here do that?

    $ grep LC /etc/ssh/*g
    /etc/ssh/ssh_config: SendEnv LANG LC_*
    /etc/ssh/sshd_config:AcceptEnv LANG LC_*
    $

    That's all normal and expected.

    Yes, they're off my system :) though I should have added -r to
    catch any ssh_config.d/* files, as in the illustration below.

    What's odd is that client *actually has* LC_NUMERIC and so on set in
    its environment. Which... is not a problem if they're all set to the
    correct values. It's weird, but not wrong. The problem for the OP was
    that one of the values was not set correctly, or at least not as
    expected.

    That's why I posted the last line about SetEnv, illustrated by:

    $ cat /etc/ssh/ssh_config.d/test.conf
    Host ahost
    SetEnv LC_PAPER=en_GB.utf8
    #
    $ ssh ahost
    Linux ahost 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64

    The programs included with the Debian GNU/Linux system are free software;
    [ … ]
    You have new mail.
    Last login: Fri Feb 16 22:41:18 2024 from 192.168.1.14
    $ 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=en_GB.utf8 ←
    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=
    $

    It's not a place I'd have immediately thought of looking.

    At this point we have no idea whether the ssh client is even a Unix/Linux system. It could be anything. It could be a literal toaster.

    More likely an æbleskiver pan?

    Cheers,
    David.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tomas@tuxteam.de@21:1/5 to David Wright on Sat Feb 17 07:00:01 2024
    On Fri, Feb 16, 2024 at 05:19:10PM -0600, David Wright wrote:
    On Fri 16 Feb 2024 at 16:25:05 (-0500), Greg Wooledge wrote:

    [...]

    At this point we have no idea whether the ssh client is even a Unix/Linux system. It could be anything. It could be a literal toaster.

    More likely an æbleskiver pan?

    But we know that all toasters run Unix, since a well-known company
    got burnt by that recall they had to do.

    On pans... I'm out of my depth, sorry.

    ;-)

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZdBKNgAKCRAFyCz1etHa RoIFAJoDQpkFFiZ132VGL7yjHQ0oTmbkyQCfbNYhJupIsPaUqZOPVVf/2KnFX28=
    =FMDj
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anssi Saari@21:1/5 to Greg Wooledge on Sat Feb 17 08:00:02 2024
    Greg Wooledge <greg@wooledge.org> writes:

    On Fri, Feb 16, 2024 at 03:34:12PM +0200, Anssi Saari wrote:
    Yah. It was ssh passing through all that. On serial console, locale
    settings are as expected:

    $ locale
    LANG=en_US.UTF-8
    LANGUAGE=en_US:en
    LC_CTYPE="en_US.UTF-8"
    LC_NUMERIC="en_US.UTF-8"
    LC_TIME="en_US.UTF-8"
    [...]

    Well then, that just changes the mystery from "happens on the Debian
    system I ssh into" to "happens on my ssh client". For some reason,
    your ssh client has all of those LC_* variables set in its environment,
    which is still quite unusual.

    Not at all, I know perfectly well where that comes from. I'd be upset if
    I didn't. I set all that in my shell config. It's a kind of a legacy contamination from remote shell machines. As I don't have root on all
    the shell machines I use, I have traditionally configured locales in
    shell init there. And at some point, I've copied those locale settings
    to my home desktop, possibly other machines too.

    I guess one of these days I'll run update-locale and clean up my shell
    config.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From debian-user@howorth.org.uk@21:1/5 to Greg Wooledge on Sat Feb 17 21:20:01 2024
    Greg Wooledge <greg@wooledge.org> wrote:

    That's all normal and expected.

    What's odd is that client *actually has* LC_NUMERIC and so on set in
    its environment. Which... is not a problem if they're all set to the
    correct values. It's weird, but not wrong. The problem for the OP
    was that one of the values was not set correctly, or at least not as expected.

    It's not weird at all. It's how many people set their machines, when
    they have logical minds and prefer YYYY-MM-DD date format rather than
    the illogical messes most countries have in their locales.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to debian-user@howorth.org.uk on Sat Feb 17 21:30:01 2024
    On Sat, Feb 17, 2024 at 08:18:41PM +0000, debian-user@howorth.org.uk wrote:
    Greg Wooledge <greg@wooledge.org> wrote:

    That's all normal and expected.

    What's odd is that client *actually has* LC_NUMERIC and so on set in
    its environment. Which... is not a problem if they're all set to the correct values. It's weird, but not wrong. The problem for the OP
    was that one of the values was not set correctly, or at least not as expected.

    It's not weird at all. It's how many people set their machines, when
    they have logical minds and prefer YYYY-MM-DD date format rather than
    the illogical messes most countries have in their locales.

    It's weird to set *every* LC_* variable when all you want to change is
    LC_TIME.

    I personally set LANG and LC_TIME. But I don't set the others. Why
    would I? That would be weird.

    unicorn:~$ locale
    LANG=en_US.utf8
    LANGUAGE=
    LC_CTYPE="en_US.utf8"
    LC_NUMERIC="en_US.utf8"
    LC_TIME=C
    LC_COLLATE="en_US.utf8"
    LC_MONETARY="en_US.utf8"
    LC_MESSAGES="en_US.utf8"
    LC_PAPER="en_US.utf8"
    LC_NAME="en_US.utf8"
    LC_ADDRESS="en_US.utf8"
    LC_TELEPHONE="en_US.utf8"
    LC_MEASUREMENT="en_US.utf8"
    LC_IDENTIFICATION="en_US.utf8"
    LC_ALL=

    As you can see, the only variables with unquoted, non-empty values are
    LANG and LC_TIME.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)