New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git-cola failed to launch when source tree is under non-ASCII directory under Windows #305

Closed
Vdragon opened this Issue Jun 15, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@Vdragon
Contributor

Vdragon commented Jun 15, 2014

Reproduce steps

  1. find a Windows command-line prompt
  2. make; make prefix=軟體\git-cola install
  3. cd 軟體\git-cola
  4. python bin/git-cola

Traceback

Traceback (most recent call last):
  File "bin/git-cola", line 365, in <module>
    sys.exit(main())
  File "bin/git-cola", line 77, in main
    return args.func(args)
  File "bin/git-cola", line 219, in cmd_cola
    context = application_init(args)
  File "share\git-cola\lib\cola\app.py", line 258, in app
lication_init
    process_args(args)
  File "share\git-cola\lib\cola\app.py", line 232, in pro
cess_args
    'Consider supplying -r <path>.\n' % repo)
UnicodeEncodeError: 'cp950' codec can't encode character u'\xb3' in position 50: illegal multibyte sequence

Reporter's environment

  • Windows 8.1 x86 64-bit(version 6.3 (build 9600))
  • Python 2.7.7(64-bit x86) is in the %PATH%
  • Locale
    • Codepage 950(Big5)
  • git-cola

davvid added a commit that referenced this issue Jun 15, 2014

app: avoid unicode errors when printing the "not a directory" error m…
…essage

If the supplied repo contains unicode characters we would error out when
writing to stderr because the encodings don't match.

Let the core.stderr() function handle it.

Related-to: #305
Reported-by: V字龍(Vdragon) <pika1021@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Jun 15, 2014

Member

Well, I was able to fix that error message based on the traceback, but I can't reproduce this one because I'm probably using utf-8 filesystem paths.

Do you know whether the filesystem paths are using a non-utf-8 encoding? I know Git itself has issues with non-utf-8 filesystem paths, and we do a lot of encoding/decoding of strings which forces us to require utf-8 for the filesystem itself.

We would need a way to get the filesystem encoding, it seems. I can try using os.getcwdu() instead of os.getcwd() as well, since that might help as well. Yep, unicode is hard ;-)

Member

davvid commented Jun 15, 2014

Well, I was able to fix that error message based on the traceback, but I can't reproduce this one because I'm probably using utf-8 filesystem paths.

Do you know whether the filesystem paths are using a non-utf-8 encoding? I know Git itself has issues with non-utf-8 filesystem paths, and we do a lot of encoding/decoding of strings which forces us to require utf-8 for the filesystem itself.

We would need a way to get the filesystem encoding, it seems. I can try using os.getcwdu() instead of os.getcwd() as well, since that might help as well. Yep, unicode is hard ;-)

davvid added a commit that referenced this issue Jun 15, 2014

core: use os.getcwdu() as our core.getcwd() implementation
decode()/encode() is lossy when using non-utf-8 filesystems.
Use getcwdu() to avoid an extra conversion.

Related-to: #305
Signed-off-by: David Aguilar <davvid@gmail.com>

davvid added a commit that referenced this issue Jun 15, 2014

cola: use core.getcwd() everywhere
Replace all uses of os.getcwd() with core.getcwd() so that we get the
proper unicode-friendly behavior.

Related-to: #305
Signed-off-by: David Aguilar <davvid@gmail.com>
@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Jun 15, 2014

Member

I added another tweak so that we avoid a decode()/encode() round trip when getting the repository path. Would you mind testing this again? There's a hope that this may have fixed this issue.

Unfortunately we may need to require utf-8 filesystem paths, but we'll see if this helps since it may make a difference. (crossing my fingers ;-))

Member

davvid commented Jun 15, 2014

I added another tweak so that we avoid a decode()/encode() round trip when getting the repository path. Would you mind testing this again? There's a hope that this may have fixed this issue.

Unfortunately we may need to require utf-8 filesystem paths, but we'll see if this helps since it may make a difference. (crossing my fingers ;-))

Vdragon pushed a commit to Vdragon/git-cola that referenced this issue Jun 16, 2014

V字龍(Vdragon)
Workaround for issue #305
I just tried to make it work, it might be wrong/dangerous/garbage.
Please review.

Signed-off-by: V字龍(Vdragon) <pika1021@gmail.com>
@Vdragon

This comment has been minimized.

Show comment
Hide comment
@Vdragon

Vdragon Jun 16, 2014

Contributor

@davvid

Do you know whether the filesystem paths are using a non-utf-8 encoding?
We would need a way to get the filesystem encoding, it seems.

The filesystem itself(NTFS) probably using UTF-16 however I suspect that os.getcwdu() should be fine dealing with this without caring which encoding are used under the hood.

I added another tweak so that we avoid a decode()/encode() round trip when getting the repository path.

I still get the exact same traceback using version c2dd395
I managed to make it launch by version 749859b but I really don't know why.

Contributor

Vdragon commented Jun 16, 2014

@davvid

Do you know whether the filesystem paths are using a non-utf-8 encoding?
We would need a way to get the filesystem encoding, it seems.

The filesystem itself(NTFS) probably using UTF-16 however I suspect that os.getcwdu() should be fine dealing with this without caring which encoding are used under the hood.

I added another tweak so that we avoid a decode()/encode() round trip when getting the repository path.

I still get the exact same traceback using version c2dd395
I managed to make it launch by version 749859b but I really don't know why.

davvid added a commit that referenced this issue Jun 16, 2014

core: always use utf-8 when encoding for stdout/stderr
Using the stdout and stderr encodings causes unicode encode errors
on Windows.

Use utf-8 when writing to stdout and stderr to fix writing unicode
error messages to the shell.

Related-to: #305
Helped-by: V字龍(Vdragon) <pika1021@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>

@davvid davvid closed this in 24fbe35 Jun 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment