On Mon, Jan 08, 2018 at 12:39:07AM +0000, Alan Gauld via Tutor wrote: > To be fair realpath() does do a tiny bit of magic in that it > checks if the file (or any part of the path) is a link (aka > shortcut) and tries to give you the actual path to the > original file - ie it follows the link.
As I actually explained in my previous email, the one which has disappeared into the aether, realpath resolves symbolic links and replaces them by the real path they represent. But that's only on Unix/Linux/Mac, on Windows it does not. Symbolic links, however, are *not* Windows shortcuts. Windows shortcuts are just a special sort of file, one which the Windows file explorer treats as an alias to another file or folder. Symbolic links on Unix are a feature of the file system itself, not a kind of file. What's the difference? With a shortcut, if you tell Python or some other program to open a shortcut, it will treat it as an ordinary file (because that's what it is!) and read from the shortcut file itself. Only programs like Windows Explorer which have been specially programmed to follow shortcuts will do so. But with a symbolic link, programs don't need to know anything about them. If you have a link: /A/link ---> /B/C/file then *any* program will treat opening /A/link as if it were /B/C/file. In other words: - under Windows, a shortcut is a regular file, unless the programmer takes special action to treat it as an alias; - under Unix, a symbolic link is an alias, unless the programmer takes special action to treat it as a symbolic link. (Aside: starting with Windows Vista, NTFS also supports symbolic links, like Unix. But few Windows users know this, or use them.) -- Steve _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
