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 cannot appear in a path amoung them \t and \n.

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 something that worked
correctly. This is obviously a bigger challenge than it appears on the
surface.

I will attempt to write some code that will work around this for my
use but I am wondering how other code resolves this issue (currently I
have an environment variable used by a python app written by some else
that seems to be suffering with this and the only solution seems to be
renaming directories).

This seems to place a large unseen burden on developers trying to
write cross-platform scripts that will work.

Thanks again

Dave

 Thu, Mar 7, 2013 at 8:11 PM, Tim Golden <report@bugs.python.org> wrote:
>
> 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 which
> characters are special, which are not, and so on. It also takes
> account of special prefixes such as r"", u"" and so on. Neither of
> these two things knows about the other. The parser doesn't know
> anything about the use the string will be put to; the os.chdir code
> doesn't know anything about the origins of the string it's receiving.
>
> This is true of Python and I doubt that it's very different for any
> other language you care to name. It's certainly true -- mutatis mutandis
> -- of C where *exactly* the same issue applies. Here's the
> MSDN page for the MS CRT _chdir function:
>
>   http://msdn.microsoft.com/en-us/library/bf7fwze1(v=vs.80).aspx
>
> In the example half way down, you can see the warning about single
> backslashes.
>
> Every language brings its learning points. In Python, if you want
> to include backslashes in a literal string, you need to prefix that
> string with an r"" prefix, eg r"c:\temp". Speaking as someone who
> uses Python on Windows on a daily basis and has done so for some years,
> this really isn't an issue once you're over the initial "Why did that
> not work?" blip. Using forward slashes is often a perfectly good way,
> sometimes not.
>
> In short, whatever else this is, it's not a Python bug and it's not
> going to change in the near future. I freely admit that the Python
> world is dominated by Unix-types for whom backslashes have little
> significance, and that can colour the emphasis which are given to
> some things but Python is very far from unworkable on Windows.
>
> TJG
>
> On 06/03/2013 21:38, Dave Humphries wrote:
>>
>> 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 path:
>> 1. \t and \n are errors when used in a path.
>> 2. A well formed Windows path with directories that start with a t or
>> n is interpreted as tabs and line feeds by Python. That is certainly
>> not expected behaviour in Windows this also means that any Python
>> built in method that uses the os.chdir() with a standard format
>> environment variable or registry setting will fail with the same
>> issue. It also sounds like any os module method will also be affected.
>> 3. This issue took 1/2 hr to resolve. This makes python unreliable to
>> use on Windows with a difficult to find bug.
>>
>> The suggestion of using forward slashes is unworkable when the scripts
>> will be used across a range of computers where environment or registry
>> variables get used.
>>
>> My suggestion is that the os methods get rewritten so that path
>> parsing rules match the expected behaviour for the platform.
>>
>> Regards,
>> Dave
>>
>> On Wed, Mar 6, 2013 at 7:50 PM, Amaury Forgeot d'Arc
>> <report@bugs.python.org> wrote:
>>>
>>> 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".
>>> Or just use forward slashes / which are allowed by Windows.
>>>
>>> ----------
>>> nosy: +amaury.forgeotdarc
>>> resolution:  -> invalid
>>> status: open -> closed
>>>
>>> _______________________________________
>>> Python tracker <report@bugs.python.org>
>>> <http://bugs.python.org/issue17366>
>>> _______________________________________
>>
>> ----------
>>
>> _______________________________________
>> Python tracker <report@bugs.python.org>
>> <http://bugs.python.org/issue17366>
>> _______________________________________
>> _______________________________________________
>> Python-bugs-list mailing list
>> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/mail%40timgolden.me.uk
>>
>
> ----------
> nosy: +tim.golden
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue17366>
> _______________________________________