Issue from Windows 10 in French

[liberodark]

Hi;

Have found issue from pywinrm i can not send command correctly if windows is in french.
Have test directly on winrm session with Enter-PSSession -ComputerName my_server

ipconfig

ipconfig

Configuration IP de Windows


Carte Ethernet Ethernet0 :

   Suffixe DNS propre … la connexion. . . :
   Adresse IPv4. . . . . . . . . . . . . .: 10.10.155.20
   Masque de sous-r‚seau. . . .ÿ. . . . . : 255.255.255.0
   Passerelle par d‚faut. . . .ÿ. . . . . : 10.10.155.254

ping

ping 1.1.1.1

Envoi d'une requˆte 'Ping'  1.1.1.1 avec 32 octets de donn‚esÿ:
D‚lai d'attente de la demande d‚pass‚.
D‚lai d'attente de la demande d‚pass‚.
D‚lai d'attente de la demande d‚pass‚.
D‚lai d'attente de la demande d‚pass‚.

Statistiques Ping pour 1.1.1.1:
    Paquetsÿ: envoy‚s = 4, re‡us = 0, perdus = 4 (perte 100%),

Have open issue on rundeck too about this :
rundeck-plugins/py-winrm-plugin#88

Best Regards

[jborean93]

What's the problem, is it the output of ipconfig having invalid chars or some other issue? If it's invalid chars you need to specify the proper codepage for Python to decode the raw bytes properly. It defaults to 437 as per open_shell. The 437 codepage is used by English US hosts but French most likely uses a different code page. This also means you can't use the high level API and need to use the low level Protocol API where you can specify the codepage and decode the bytes as needed.

[m1024]

I have the same issue with codepage which is differ from default (437).

I found that it is possible to pass the codepage parameter to Protocol.open_shell() method and then everything will be processed correctly. Moreover, there are tests that check the work of this method with Unicode encoding. Unfortunatelly, Session.run_cmd() and Session.run_ps() methods don't allow to pass this argument and now they call open_shell() with default arguments.

Can you explain why other encodings are not supported?
The advice to use a low-level API from the previous comment seems extremely odd.

[nitzmahone]

The high-level API has a number of shortcomings- automatic handling of non-default encodings is a big one. It's not easily addressed without a lot of effort- there are many corner cases that aren't always consistent, and since the current maintainers (and most other users) don't use it, it's difficult to justify spending time fixing it. Unless you're running the client Python itself with the same default encoding (almost always a bad idea, and getting worse as time goes on), there's not a great "easy button" solution with the high-level API.

You might also want to consider looking at pypsrp, which is a much newer and more actively-maintained project- IIRC it handles non-default encodings much more consistently without onerous requirements on the caller.