environment variables are not decoded properly
Bug #832028 reported by
Vincent Ladeuil
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Medium
|
Martin Packman |
Bug Description
As mentioned in https:/
Addressing this may require to explicitly declare which environment variables can be paths so the file system encoding can be respected for them and the user encoding tried for the others.
windows probably needs a different policy of always using mbcs though (comments welcome this is roughly what I remember from old discussions).
Related branches
lp:~gz/bzr/path_from_environ_832028
- Vincent Ladeuil: Needs Fixing
-
Diff: 372 lines (+87/-99)4 files modifiedbzrlib/osutils.py (+31/-24)
bzrlib/tests/test_lockdir.py (+2/-1)
bzrlib/tests/test_osutils.py (+0/-6)
bzrlib/win32utils.py (+54/-68)
Changed in bzr: | |
assignee: | nobody → Martin Packman (gz) |
status: | Confirmed → In Progress |
Changed in bzr: | |
milestone: | none → 2.5b5 |
status: | In Progress → Fix Released |
To post a comment you must log in.
For common cases like getting an integer or other simple values out of the environment, it should be possible to always do the right thing. Path handling in bzr is generally confused by corner cases, here the main issues are:
* Python 2 doesn't give access to the unicode environment block on windows only the 'ANSI' compatiblity apis.
* Both the environment and paths can be arbitrary bytes on nix so decoding to unicode is never fully correct.