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 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 <rep...@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 >> <rep...@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 <rep...@bugs.python.org> >>> <http://bugs.python.org/issue17366> >>> _______________________________________ >> >> ---------- >> >> _______________________________________ >> Python tracker <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue17366> > _______________________________________ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17366> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
