Amaury Forgeot d'Arc added the comment:
> My expectation was that a platform os.chdir would parse the string for
> these characters and do something intelligent with them i.e a legal
> path from any of the systems (mac, linux or windows) passed in as a
> string to os.chdir would be converted to s
Dave Humphries added the comment:
Thanks for the thoughtful response Tim,
I am obviously not being clear with the way I express this. os.chdir
uses a common string but these strings represent a special subset of
strings. I'm not sure about mac and linux but windows has arrange of
characters that
Tim Golden added the comment:
Dave, you seem to misunderstand what's happening here: the os.chdir
function doesn't have access to the characters which are typed in
the script or in the interpreter. It receives a Python string object.
The parser etc. which constructs the string object determines w
Dave Humphries added the comment:
Hi Amaury,
As I can't reopen the bug I will have to add it here (or open a new bug report).
The issue was about the string used in os.chdir() particularly.
While this is expected behaviour in a python string it is not expected
behaviour from a well formed file p
Amaury Forgeot d'Arc added the comment:
The backslash \ has a special meaning in strings: \n is the new line character,
and \t is the tab character:
http://docs.python.org/2/reference/lexical_analysis.html#string-literals
Try to print the string!
You could use \\, or raw strings r"like this".
New submission from Dave Humphries:
os.chdir missed a back slash in rewriting a file path see example below (the
extra backslash was missing from the trunk directory).
Modifying the path with an extra slash enabled this to work for some reason.
(os windows 8 64 bit Python 2.7.3 (default, Apr 1
