> 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.
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
characters.
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.
> 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 = subprocess. call([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 argv()" Windows itself is decoding the command
raise an appropriate *error* when decoding the command line arguments. However,
since we now use "get_unicode_
line arguments, and I'm pretty sure all of its codepages support all 8-bit
characters.
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.