"env" parameter to "popen" won't accept Unicode on Windows - minor Unicode bug
Diez B. Roggisch
deets at nospam.web.de
Tue Jan 15 04:47:53 EST 2008
John Nagle wrote:
> Benjamin wrote:
>> On Jan 14, 6:26 pm, Bjoern Schliessmann <usenet-
>> mail-0306.20.chr0n... at spamgourmet.com> wrote:
>>> John Nagle wrote:
>>>> It turns out that the strings in the "env" parameter have to be
>>>> ASCII, not Unicode, even though Windows fully supports Unicode in
>>>> CreateProcess.
That's of course nonsense, they don't need to be ascii, they need to be
byte-strings in whatever encoding you like.
>>> Are you sure it supports Unicode, not UTF8 or UTF16? Probably using
>>> something like u"thestring".encode("utf16") will help.
>> Otherwise: bugs.python.org
John's understanding of the differences between unicode and it's encodings
is a bit blurry, to say the least.
> Whatever translation is necessary should be done in "popen", which
> has cases for Windows and POSIX. "popen" is supposed to be cross-platform
> to the extent possible. I think it's just something that didn't get fixed
> when Unicode support went in.
Sure thing, python will just magically convert unicode to the encoding the
program YOU invoke will expect. Right after we introduced the
solve_my_problem()
built-in-function. Any other wishes?
If I write this simple program
------ test.py -------
import os
import sys
ENCODDINGS = ['utf-8', 'latin1']
os.env["MY_VARIABLE"].encode(ENCODINGS[int(sys.argv[1])])
------ test.py -------
how's python supposed to know that
suprocess.call("python test.py 0", env=dict(MY_VARIABLE=u'foo'))
needs to be UTF-8?
Diez
More information about the Python-list
mailing list