New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2.7] subprocess.call fails with unicode strings in command line #45239
Comments
On Windows, subprocess.call() fails with an exception if either the executable or any of the arguments contain upper level characters. See below:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python25\lib\subprocess.py", line 443, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python25\lib\subprocess.py", line 593, in __init__
errread, errwrite)
File "C:\Python25\lib\subprocess.py", line 815, in _execute_child
startupinfo)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xc5' in position 5: ordinal not in range(128) |
Python's default character coding is 'ascii' which can't convert unicode > 127 into chars. Forcing the unicode string to encode as 'iso-8859-1' eg. resolves the problem and runs the correct command. |
Sorry, I should have been more specific. I'm looking for a general solution, not just one for characters in iso-8859-1. For instance, I need to execute a subprocess where the executable or the arguments may contain Japanese characters. So another example would be: |
I tried to fix this problem using CreateProcessW. I don't know Python C API well, maybe I'm doing |
We're having the same problem. My quick fix was to patch subprocess.py |
ocrean-city's patch applied cleanly with trunk and it works for me. |
The first patch will introduce regressions for strings that cannot be I'd prefer the python-only patch, except for the "sys=sys" argument to |
I like the C patch better. It only tries to decode non-unicode objects |
There is slight difference between C and python patch. Actually, python version patch may not work if the string is unicode and On the other hand, the C version patch. I don't think fall-back is |
I fail to see why subprocess.call(cmd.encode('whatever')) is not a general solution. Auto-encoding strikes me as wrong. Someone who wants that should write their own wrapper. In any case, 2.7 is out and closed to new features, while 3.x fixes this and numerous other unicode issues. |
Assume cmd contains Japanese characters and my system is Chinese windows. subprocess.call expect the argument is encoded in mbcs, which is cp950. However, cp950 encoding doesn't contain Japanese characters. subprocess.call(cmd.encode('cp950')) will fail because cp950 doesn't contain Japanese characters. |
Thanks for the simple explanation. |
So Terry, can you reopen this bug then? It's not out of date. |
I will not reopen this now for the reasons I already stated after "In any case ...". To expand on that.
The discussion shows disagreement on both the goal and approach to change. I am dubious that there will be an acceptable general solution. Even if this is persuasively seen as a bug and there is a good patch, I am dubious that any of the current developers will want to spent the necessary time to properly review a workaround to an issue that was already fixed the right way in 3.x. |
To confirm the situation on 3.x: a unicode string with non-ascii-encodable characters is fine. The easy test here in the uk is a pound sign: <code> FILENAME = "abc£.bat"
FILENAME.encode ("ascii")
#
# UnicodeEncodeError
#
with open (FILENAME, "w") as f:
f.write ("echo hello\n") subprocess.call ([FILENAME]) # "hello" output as expected </code> So no action for 3.x. I'm sympathetic (in principle) to making a change to 2.7 but I haven't looked over the "competing" patches and assessed the ins-and-outs. |
Although this issue is very old, in case anyone else like us need this functionality I created a package that implements the proposed C-fix. We really want to upgrade our app to Python 3, but currently lack the manpower to go over our app line by line. It's not a simple 2to3 conversion, unfortunately. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: