On Sun, Jul 1, 2018 at 1:58 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Jul 1, 2018 at 10:20 AM, eryk sun <eryk...@gmail.com> wrote:
>> On Sat, Jun 30, 2018 at 11:42 PM, Chris Angelico <ros...@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.
--
https://mail.python.org/mailman/listinfo/python-list
