Python Popen failing to use proper encoding in Windows PowerShell
I am running my Python script in Windows PowerShell, and the script should run another program using Popen, then pipe the output of that program (Mercurial, actually) for use in my script. I am getting an encoding error when I try to execute my script in PowerShell.
I am quite sure it is happening because Python is not using the correct encoding that PowerShell is using, when getting the output of the Popen call. The problem is that I don't know how to tell Python to use the correct encoding.
My script looks like
# -*- coding: utf-8 -*- #... some imports proc = Popen(["hg", "--cwd", self.path, "--encoding", "UTF-8"] + list(args), stdout=PIPE, stderr=PIPE) #... other code
When I run this script on Linux, I have no problems whatsoever. I can also run the script in Windows 7 Home Premium 64-bit using PowerShell with no problems. The PowerShell in this Windows 7 is using the code page 850, that is, the output of chcp is 850 ("ibm850").
However, when I run the script in a Windows 7 Starter 32-bits using a PowerShell that has by default the encoding cp437 (chcp = 437), I get the following error from Python (version 2.7.2):
File "D:\Path\to\myscript.py", line 55, in hg_command proc = Popen(["hg", "--cwd", self.path, "--encoding", "UTF-8"] + list(args), stdout=PIPE, stderr=PIPE) File "C:\Program files\Python27\lib\subprocess.py", line 679, in __init__ errread, errwrite) File "C:\Program files\Python27\lib\subprocess.py", line 852, in _execute_child args = list2cmdline(args) File "C:\Program files\Python27\lib\subprocess.py", line 615, in list2cmdline return ''.join(result) UnicodeDecodeError: 'utf8' codec cant decode byte 0xe3 in position 0: unexpected end of data
I have tried the following, with no success (i.e., the above error report stays the same):
- Remove the line # -*- coding: utf-8 -*- from my script.
- Remove the -- encoding UTF-8 option for running Mercurial through Popen in my script.
- Change the encoding to chcp 850 in PowerShell before executing my script.
- Many other miscellaneous Python hacks I've found in other Stack Overflow answers.
For my specific details, my whole source code is available here in BitBucket. hgapi.py is the script that gives the error.
UPDATE: The script is being called by this other script, which is setting the encoding like this
This line looks important, because if I comment it out, I get a different error:
UnicodeDecoreError: 'ascii' codec cant decode byte 0xe3 in position 0: ordinal not in range(128)
Try to change the encoding to cp1252. Popen in Windows wants shell commands encoded as cp1252. This seems like a bug, and it also seems fixed in Python 3.X through the subprocess module: http://docs.python.org/library/subprocess.html
import subprocess subprocess.Popen(["hg", "--cwd", self.path, "--encoding", "UTF-8"] + list(args), stdout=PIPE, stderr=PIPE)
Your problem maybe can be solved through smart_str function of Django module.
Use this code:
from django.utils.encoding import smart_str, smart_unicode # the cmd should contain sthe string with the commsnd that you want to execute smart_cmd = smart_str(cmd) subprocess.Popen(smart_cmd)
You can find information on how to install Django on Windows here. You can first install pip and then you can install Django by starting a command shell with administrator privileges and run this command:
pip install Django
This will install Django in your Python installation's site-packages directory.
After using from __future__ import unicode_literals I started getting the same error but in a different part of the code:
out, err = [x.decode("utf-8") for x in proc.communicate()]
Gave the error
UnicodeDecodeError: 'utf8' codec cant decode byte 0xe3 in position 33 ....
Indeed, x was a byte string with \xe3 (which is ã in cp1252) included. So instead of using x.decode('utf-8'), I used x.decode('windows-1252') and that gave me no bugs. To support any kind of encoding, I ended up using x.decode(sys.stdout.encoding) instead. Problem solved.
And that was in Python 3.2.2 with the Windows 7 Starter computer, but Python 2.7 on the same computer also worked normally.