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
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
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
>
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
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
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
* 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"
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")
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
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
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.
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
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
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
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
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
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
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,
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.
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
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
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?
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
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
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
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
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?
--
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
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
> 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
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
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
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.
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
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*
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
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
37 matches
Mail list logo
