windows netsh/route output translated to English in mintty

windows netsh/route output translated to English in mintty

[Ilya Basin]

Hi. One of my PCs still has Windows 7 and I noticed that when I run 
netsh interface ipv4 show route
or
route print

In Mintty, the output is translated to English and when I run these commands from Cygwin started in a Windows console the output is in the same language as the OS. Does Cygwin do that?

Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or even setsid.

And I also noticed that when the "Interface List" section of "route print" is translated to English the national interface names containing "Microsoft ISATAP" are omitted completely, including the newlines so the output looks like this:

    ...
      1...........................Software Loopback Interface 1
     12...00 00 00 00 00 00 00 e0  14...00 00 00 00 00 00 00 e0  16...00 00 00 00 00 00 00 e0  18...00 00 00 00 00 00 00 e0  20...00 00 00 00 00 00 00 e0  26...00 00 00 00 00 00 00 e0 ===========================================================================
    
    IPv4 Route Table
    ...

Does anybody know the reason?

Re: windows netsh/route output translated to English in mintty

[Takashi Yano]

On Thu, 7 Apr 2022 11:38:28 +0300
Ilya Basin wrote:
> Hi. One of my PCs still has Windows 7 and I noticed that when I run 
> netsh interface ipv4 show route
> or
> route print
> 
> In Mintty, the output is translated to English and when I run these commands from Cygwin started in a Windows console the output is in the same language as the OS. Does Cygwin do that?
> 
> Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or even setsid.
> 
> And I also noticed that when the "Interface List" section of "route print" is translated to English the national interface names containing "Microsoft ISATAP" are omitted completely, including the newlines so the output looks like this:
> 
>     ...
>       1...........................Software Loopback Interface 1
>      12...00 00 00 00 00 00 00 e0  14...00 00 00 00 00 00 00 e0  16...00 00 00 00 00 00 00 e0  18...00 00 00 00 00 00 00 e0  20...00 00 00 00 00 00 00 e0  26...00 00 00 00 00 00 00 e0 ===========================================================================
>     
>     IPv4 Route Table
>     ...
> 
> Does anybody know the reason?

That's because code page is set to CP_UTF8 (65001) by default
in pty without pseudo console support for a certain reason.
https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html

You can change the code page by
chcp.com <code page>

Windows program does not reffer to TERM, LC_ALL, etc. but code page.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: windows netsh/route output translated to English in mintty

[Brian Inglis]

On 2022-04-07 03:35, Takashi Yano wrote:
> On Thu, 7 Apr 2022 11:38:28 +0300
> Ilya Basin wrote:
>> Hi. One of my PCs still has Windows 7 and I noticed that when I run
>> netsh interface ipv4 show route
>> or
>> route print
>>
>> In Mintty, the output is translated to English and when I run these commands from Cygwin started in a Windows console the output is in the same language as the OS. Does Cygwin do that?
>>
>> Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or even setsid.
>>
>> And I also noticed that when the "Interface List" section of "route print" is translated to English the national interface names containing "Microsoft ISATAP" are omitted completely, including the newlines so the output looks like this:
>>
>>      ...
>>        1...........................Software Loopback Interface 1
>>       12...00 00 00 00 00 00 00 e0  14...00 00 00 00 00 00 00 e0  16...00 00 00 00 00 00 00 e0  18...00 00 00 00 00 00 00 e0  20...00 00 00 00 00 00 00 e0  26...00 00 00 00 00 00 00 e0 ===========================================================================
>>      
>>      IPv4 Route Table
>>      ...
>>
>> Does anybody know the reason?
> 
> That's because code page is set to CP_UTF8 (65001) by default
> in pty without pseudo console support for a certain reason.
> https://cygwin.com/pipermail/cygwin-developers/2020-August/011951.html
> 
> You can change the code page by
> chcp.com <code page>
> 
> Windows program does not reffer to TERM, LC_ALL, etc. but code page.

In mintty, see Options/Text/Locale|Character set or .minttyrc entries:

#                               # Locale ll[l]_CC language_country
Locale=en_CA
#                               # Character set UTF-8|...
Charset=UTF-8

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: windows netsh/route output translated to English in mintty

[Andrey Repin]

Greetings, Ilya Basin!

> Hi. One of my PCs still has Windows 7 and I noticed that when I run 
> netsh interface ipv4 show route
> or
> route print

> In Mintty, the output is translated to English and when I run these
> commands from Cygwin started in a Windows console the output is in the same
> language as the OS. Does Cygwin do that?

No, it is netsh does.
It checks the console codepage and outputs in english if it is not an OEM
CP.

> Secondly, it doesn't seem to be affected by TERM= LC_ALL= , redirections or even setsid.

Right.

> And I also noticed that when the "Interface List" section of "route print"
> is translated to English the national interface names containing "Microsoft
> ISATAP" are omitted completely, including the newlines so the output looks like this:

>     ...
>       1...........................Software Loopback Interface 1
>      12...00 00 00 00 00 00 00 e0  14...00 00 00 00 00 00 00 e0  16...00 00
> 00 00 00 00 00 e0  18...00 00 00 00 00 00 00 e0  20...00 00 00 00 00 00 00
> e0  26...00 00 00 00 00 00 00 e0
> ===========================================================================
>     
>     IPv4 Route Table
>     ...

> Does anybody know the reason?

Microsoft stupidity.


-- 
With best regards,
Andrey Repin
Tuesday, April 19, 2022 21:13:47

Sorry for my terrible english...