Code review comment for lp:~jameinel/bzr/2.1.0b4-win32-unsupported_encoding_commit_message

John A Meinel (jameinel) wrote :

> It is possible to give bazaar commit messages in the wrong encoding under
> windows using subprocess, but as what happens depends on the codepage, it's
> not very interesting to test. Again, would prefer if this didn't check
> sys.platform but confirmed that it does turn the failure into a n/a here.

>>> p =[sys.executable, '-c',
                         'from bzrlib.win32utils import get_unicode_argv;'
                         'print get_unicode_argv()',
    'foo', 'ba\x99'])
[u'foo', u'ba\u2122']

This code is testing that passing something to the process will cause it to
raise an appropriate *error* when decoding the command line arguments. However,
since we now use "get_unicode_argv()" Windows itself is decoding the command
line arguments, and I'm pretty sure all of its codepages support all 8-bit

I'm not positive to that fact, as I haven't tried different OS installs
(Russian Windows, etc.)

I can say that the meaning of 'ba\x99' will probably depend on the current
codepage, but I haven't found a way for the subprocess to think it has failed
to read its arguments. (A user can't force the arguments in such a way that the
client can tell the arguments aren't meaningful.)

That would be different if you could, for example, set your code-page to a
multi-byte sequence like UTF-8.

However, this *isn't* about getting commit message encodings wrong, this is
about failing to decode command line arguments.

« Back to merge proposal