Re: [win-pv-devel] New windows pv drivers question

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
[snip]
> > Traceback (most recent call last):
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 365,
> > in <module
> > >
> >     build_sln(driver, release, 'x64', debug[sys.argv[1]], vs)
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 138,
> > in build_s
> > ln
> >     msbuild(platform, configuration, 'Build', name + '.sln', '', vs)
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 122,
> > in msbuild
> >
> >     status = shell([bin], dir)
> >   File "C:\Users\Emilio\Desktop\pvdrivers\xenbus\build.py", line 100,
> > in shell
> >     print(line.rstrip())
> >   File "C:\Python34\lib\encodings\cp850.py", line 19, in encode
> >     return codecs.charmap_encode(input,self.errors,encoding_map)[0]
> > UnicodeEncodeError: 'charmap' codec can't encode character '\u2026' in
> > position
> > 28: character maps to <undefined>
> 

I believe I have figured this one out. I think it is the use of 
universal_newlines=True in the subprocess.Popen() call. Googling around, it 
appears  this is unsafe (for at least some versions of python) if the system 
default encoding is unicode. I think the problem can just be avoided by not 
setting universal_newlines, but I think the byte string coming back from Popen 
should also be decoded with the system default encoding before being displayed. 
I'll send a patch shortly.

  Paul

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel