error in os.chdir

[eryk sun]

On Sat, Jun 30, 2018 at 11:42 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, Jul 1, 2018 at 9:36 AM, eryk sun <eryksun at gmail.com> wrote:
>> On Sat, Jun 30, 2018 at 11:21 AM, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Sat, Jun 30, 2018 at 9:05 PM, Sharan Basappa
>>> <sharan.basappa at gmail.com> wrote:
>>>>
>>>> 0
>>>> down vote
>>>> favorite
>>>>
>>>> I need to change directory to my local working directory in windows and then open a file for processing.
>>>> Its just a 3 lines code, as below:
>>>> import csv
>>>> import os
>>>> os.chdir('D:\Projects\Initiatives\machine learning\programs\assertion')
>>>> The error is as follows:
>>>> WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: 'D:\Projects\Initiatives\machine learning\programs\x07ssertion'
>>>> Notice x07 character that has replaced character x07.
>>>> I have a similar code but that goes through fine:
>>>> import csv
>>>> import os
>>>> os.chdir('D:\Projects\Initiatives\machine learning\programs')
>>>
>>> Use forward slashes instead of backslashes for all paths.
>>>
>>> os.chdir('D:/Projects/Initiatives/machine learning/programs')
>>
>> Only use forward slashes for legacy DOS paths passed to Windows API
>> functions. Do not use forward slashes for paths in command line
>> arguments, \\?\ prefixed paths, or registry paths.
>
> "Legacy" implies that it's the old standard that is now deprecated,

I did not mean to imply that DOS paths are deprecated. That's not what
legacy means to me. I only meant that they're inherited from an old
system. The native API does not use forward slash as a path separator.
It's just a name character in NT (except in most file-system
implementations, which reserve forward slash as an invalid filename
character to avoid confusion). This doesn't affect device names. You
can call DefineDosDevice or native NtCreateSymbolicLinkObject to
create a device name with a slash in it.

The Windows file API supports forward slash as a path separator, which
it implements by rewriting the path via ntdll library functions such
as RtlDosPathNameToNtPathName_U_WithStatus. Paths prefixed with \\?\
bypass this normalization step, so they cannot use forward slash as
the path separator.

> Registry paths aren't file paths,

You said to use forward slash for "all paths".

Also, from the POV of the NT API, registry paths and file paths are
all just paths, such as "\Registry\Machine\Software" and
"\Device\HarddiskVolume2\Program Files". The executive's Object
Manager parses the path up to an object with a ParseProcedure (e.g.
"Registry" or "HarddiskVolume2"), which in turn parses the rest of the
path. Registry paths in the Windows API are closer to native NT paths,
since they don't support forward slash as a path separator and
implement relative paths NT style, i.e. relative to a Key handle. The
Windows API doesn't expose handle-relative paths for file paths, but
it uses this feature implicitly by keeping a handle open for the
process working directory.

> command line arguments are interpreted by the target program (and in many
> MANY cases, forward slashes are absolutely fine),

You can't generalize this. In many cases it's not ok. Most
command-line utilities that use ulib make a simply assumption when
parsing the command line that forward slash is used for options
(switches). It's best to normalize paths in a command line via
os.path.normpath.