Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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 signature.asc Description: PGP signature
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
* 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 signature.asc Description: PGP signature
Re: Does "LC_ALL=C" work on all shells?
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'
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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>.
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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'
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
On 13/02/24 at 23:23, Nicolas George wrote: Will Mengarini (12024-02-13): * Greg Wooledge [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
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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"?
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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?
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
Will Mengarini (12024-02-13): > * Greg Wooledge [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
Re: Does "LC_ALL=C" work on all shells?
> 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 [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 [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.
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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, cono...@panix.com, http://www.johncon.com/
Re: Does "LC_ALL=C" work on all shells?
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
Re: Does "LC_ALL=C" work on all shells?
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.
Re: Does "LC_ALL=C" work on all shells?
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
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