bzr 0.92.0.candidate.1 BUG

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grinchishin V. wrote:
> Sequence of actions:
> 1. bzr init
> 2. bzr add *
> 3. bzr ci -> got bug.
> 

The quick work around is to do: bzr ci -m "Commit message"
rather than spawning an editor to edit your commit message.


This is because you are sitting in a directory with Unicode characters, but
your sys.getfilesystemencoding() is returning ASCII.

Or maybe...

=== modified file 'bzrlib/msgeditor.py'
- --- bzrlib/msgeditor.py 2007-10-04 05:35:10 +0000
+++ bzrlib/msgeditor.py 2007-11-06 16:58:07 +0000
@@ -58,7 +58,7 @@
         edargs = e.split(' ')
         try:
             ## mutter("trying editor: %r", (edargs +[filename]))
- -            x = call(edargs + [filename])
+            x = call(edargs + [filename.encode(sys.getfilesystemencoding())])
         except OSError, e:
            # We're searching for an editor, so catch safe errors and continue
            if e.errno in (errno.ENOENT, ):


It is possible that 'call()' is using locale.getdefaultencoding() (which seems
to be ascii) rather than sys.getfilesystemencoding().

However, because it is being passed as a command line argument, we probably
should be using locale.getdefaultencoding()...

So we need to figure out why your system is claiming that you cannot spawn a
process with non-ascii parameters.

Or we need the update which will use something like $TMPDIR if it fails to use
the current working directory.

Alexander, I think you've spent more time looking at this. Do you have any ideas?

Certainly to start with, we need to figure out how Windows likes to take
arguments which have non-ascii characters. It seems like it might depend on the
EDITOR, which is sort of a bad place to be.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMJ4jJdeBCYSNAAMRAnjvAJ9UjBLVigPc7R5xcXXrF8J5h1sXXwCg2QC6
+GG6ihwr7khlRaYkDA8Iy+c=
=mj4X
-----END PGP SIGNATURE-----