[MERGE][#139318] bzr send @ win32: ensure that command line to invoking Thunderbird is 8-bit string, not unicode (because subprocess does not understand non-ascii unicode)

Aaron Bentley aaron at aaronbentley.com
Thu Feb 28 13:12:03 GMT 2008

Hash: SHA1

Alexander Belchenko wrote:
> Aaron Bentley пишет:
>> Alexander Belchenko wrote:
>>> I think I should not
>>> touch paths (neither path to executable nor attachment).
>> I think this isn't right.  If the path to an executable or attachment is
>> unicode, then on Windows, won't Python raise a UnicodeEncodeError?
> It's work for me, because executable 'C:\Program Files\Mozilla
> Thunderbird\thunderbird.exe'
> is actually ascii string.

Yes, but you said it would be *wrong* to encode the path to the command.
 I would like you to justify your statement, because I think it's wrong.
 We know that python isn't auto-encoding on command arguments on
Windows-- that's why we have this bug.  So it seems quite likely that we
also have to encode command paths.

> And ThunderbirdClient class turns attachment
> path to URL.

And therefore it's already a bytestring, not unicode?  Fair enough.

> For executable path I agree, but not for attachment path. Otherwise
> Thunderbird
> will produce wrong URL.

It took me a while to understand you were saying that the URL was
already encoded.  Re-encoding it wouldn't produce a wrong URL.  If the
URL was ascii only, it would have no effect.  If it included high-bit
characters, then calling .encode would force it to unicode, and that
would raise an exception.

>>> +            cmdline = _get_compose_8bit_commandline(name, to, subject,
>>> +                attach_path)
>> Does this actually work?  It looks like it should be
>> self._get_compose_8bit...
> I don't understand your note. Yes, it works, I tested it manually.

_get_compose_8bit_commandline is a method, not a function.  But you're
calling it like a function.

When *I* test it, I get this:

$ ./bzr send
Using saved location: file:///home/abentley/bzrrepo/others/bzr.dev/
bzr: ERROR: exceptions.NameError: global name
'_get_compose_8bit_commandline' is not defined

Traceback (most recent call last):
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/commands.py", line
834, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/commands.py", line
790, in run_bzr
    ret = run(*run_argv)
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/commands.py", line
492, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/builtins.py", line
4070, in run
    kwargs.get('from', '.'), mail_to, message)
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/builtins.py", line
4166, in _run
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/mail_client.py",
line 68, in compose_merge_request
    'x-patch', '.patch')
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/mail_client.py",
line 131, in compose
    self._compose(prompt, to, subject, pathname, mime_subtype, extension)
  File "/home/abentley/bzr/bzr.ab.integration/bzrlib/mail_client.py",
line 147, in _compose
    cmdline = _get_compose_8bit_commandline(name, to, subject,
NameError: global name '_get_compose_8bit_commandline' is not defined

>> I suppose drive letters can't be non-ascii, so this probably doesn't
>> matter, but it would be nice to do escape(win32_path[0].upper()) for
>> consistency.
> I think it's redundant here. Please, don't force me do this.
> I think it's not good idea.

It was just a suggestion.

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list