Fred Drake wrote:
> On Oct 24, 2007, at 4:23 PM, Facundo Batista wrote:
>> There (and always talking in windows), the OP says the in Py2.4
>> os.path.exists("nul") returned True and now in 2.5 returns False. Note
>> that "nul" is an special file, something like /dev/null.
>
> It's special, but in a different way. /dev/null really exists in the
> Unix filesystem; "nul" is more magical than that.
>
> What's more, it has peers: "prn", "com1" and others like that.
It's even worse than that, because file extensions are ignored in this
magical-ness:
C:\Documents and Settings\User>type nul
C:\Documents and Settings\User>type nul.lst
C:\Documents and Settings\User>type foo.lst
The system cannot find the file specified.
> I don't know what the right way to handle these is (I'm no Windows
> guru, or even regular user), but it's important to realize that the
> pain of the specialness isn't limited. :-)
http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part3/proch17.mspx?mfr=true
gives the list as CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3,
PRN, NUL; but I can't imagine testing against that list would be the
best idea. For example,
http://www.microsoft.com/technet/solutionaccelerators/cits/interopmigration/unix/unixbld/unixbld4.mspx
adds CLOCK$, among others (although I don't find CLOCK$ to be special,
it's rumored to be an NT only thing, and I'm running XP). So I think
implementing Facundo's option 2 (test for "nul") will not work in the
general case for finding "special files" (don't forget to throw in mixed
case names). I hate to think of trying to match Windows' behavior if
there are multiple dots in the name.
I think I'd leave the current behavior of calling the kernel function,
even though it varies based on Windows version (if I'm reading the issue
correctly).
Eric.
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
