error in os.chdir

[eryk sun]

On Sun, Jul 1, 2018 at 1:58 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, Jul 1, 2018 at 10:20 AM, eryk sun <eryksun at gmail.com> wrote:
>> On Sat, Jun 30, 2018 at 11:42 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>> "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.
>
> Unless you are Humpty Dumpty, you can't just say "that's not what it
> means to me". Sorry. People WILL see "legacy" as an implication that
> "only the old stuff goes that way". You are responding to a thread in
> which someone used a perfectly ordinary file path, and you said that
> only legacy paths can be done with slashes. At best, you are
> technically correct and functionally deceptive.

That's fine, and I understand how I could have been misconstrued. I
clarified what I meant. I did not intend to be deceptive.

>>> Registry paths aren't file paths,
>>
>> You said to use forward slash for "all paths".
>
> *facepalm* Okay. I said "all paths", but I did not refer to XPath
> (although that also uses the slash character), nor registry paths, nor
> the footpath that runs parallel to the road outside my house. You're
> absolutely right, there are no forward slashes in the path that leads
> to my door. My bad. I'm sorry that the word "all" has to be
> interpreted within the context of the thread that it was used in.
> Whoops.

I also clarified why to me your "all paths" statement needs to be
qualified to the domain. I use the native API a lot, so for me
registry and file paths are just paths. It's only the Windows API that
separates the two and only the Windows API that allows forward slash
as a path separator in file paths.

>>> 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.
>
> Ahh but I *can* generalize it. In many cases, forward slashes ARE
> fine, and I can prove it by listing off large numbers of programs that
> are perfectly happy to receive file paths with slashes in them.
> Surprise surprise, most of those programs are going to be taking those
> paths and handing them straight to the OS. In other words: THE OS
> SUPPORTS SLASHES. Does this surprise anyone?

There are many cases for common command-line utilities that do not
support paths with forward slash -- even if you disambiguate by
putting the path in double quotes. In the following examples, I have a
file named "C:\Temp\test.txt" and an existing directory named
"C:\Temp\dest".

Internal CMD commands:

    C:\>dir /b "C:/Temp/test.txt"
    File Not Found

    C:\>type "C:/Temp/test.txt"
    The system cannot find the file specified.

    C:\>copy "C:/Temp/test.txt" "C:/Temp/dest"
    The system cannot find the file specified.
            0 file(s) copied.

    C:\>del "C:/Temp/test.txt"
    The system cannot find the path specified.

External utility commands:

    C:\>find "spam" "C:/Temp/*.txt"
    File not found - C:TEST.TXT

    C:\>findstr "spam" "C:/Temp/*.txt"
    FINDSTR: Cannot open C:test.txt

    C:\>fc "C:/Temp/test.txt" "C:/Temp/*.txt"
    FC: cannot open C:/TEMP/TEST.TXT - No such file or folder

    C:\>forfiles /p "C:/Temp" /m *.txt
    ERROR: The directory name is invalid.

    C:\>where /r "C:/Temp" test.txt
    ERROR: Invalid directory specified.

    C:\>icacls "C:/Temp/*.txt"
    C:test.txt: The system cannot find the file specified.
    Successfully processed 0 files; Failed processing 1 files

    C:\>takeown /f "C:/Temp/test.txt"
    ERROR: File or Directory not found.

    C:\>xcopy.exe "C:/Temp/test.txt" "C:/Temp/dest"
    0 File(s) copied

In the following case I create "C:\Temp\dest\test.txt" to be replaced
using replace.exe, which silently fails to replace the file:

    C:\>replace "C:/Temp/test.txt" "C:/Temp/dest"

    C:\>fc C:\Temp\test.txt C:\Temp\dest\test.txt
    Comparing files C:\TEMP\test.txt and C:\TEMP\DEST\TEST.TXT
    ***** C:\TEMP\test.txt
    spam
    ***** C:\TEMP\DEST\TEST.TXT
    eggs
    *****

> So what if, internally, that's done by converting them to backslashes?
> No Python program needs to care. In fact, there are other conversions,
> too - the underlying file system is most likely using UTF-16 paths,
> but your Python program needn't use UTF-16. No, it simply uses a plain
> old string literal - a Unicode string. The OP need not be concerned
> about any of these fiddlinesses, unless in some way they actually
> affect Python.

A few minor changes in in wording are both technically correct and
don't make the text any more difficult to understand. You're the one
blowing this up beyond proportion and making a mountain out of a small
technical-correction mole hill. Please just let it pass.