directory? vs. file? on WIN32

[DrDave]

Why is there this subtle difference in results?

Code Select Expand

(set 'test-dir1 "C:/Program Files/programming")
(set 'test-dir2 "C:/Program Files/programming/")

(directory? test-dir1)
-->true
(directory? test-dir2)
-->true
(file? test-dir1)
-->true
(file? test-dir2)
-->nil
The manual states for true?

This function will also return true for directories.

That suggests  to me that I should see true? return true for any argument that directory? also returns true. But as we see above, this is not the behavior.



In addition, I'm not so sure that I like the idea of file? rerturning true for something that is not actually a file, especially when directory? is available.

[newBert]

Why have I got these results on my computer ?

Code Select Expand

newLISP v.10.0.1 on Win32 IPv4, execute 'newlisp -h' for more info.

> (set 'test-dir1 "C:/Program Files/programming")
"C:/Program Files/programming"
> (set 'test-dir2 "C:/Program Files/programming/")
"C:/Program Files/programming/"
> (directory? test-dir1)
nil
> (directory? test-dir2)
nil
> (file? test-dir1)
nil
> (file? test-dir2)
nil
>

Have 'test-dir1' and 'test-dir2' to be real directories/files to realize the tests ?

Sorry for this probably rather silly question :)



P.S.: *really* silly question, I do the tests again (with a real "C:/Program Files/programming") and I've got the same results as yours ...

> (directory? test-dir1)

true

> (directory? test-dir2)

true

> (file? test-dir1)

true

> (file? test-dir2)

nil

>

[cormullion]

That suggests  to me that I should see true? return true for any argument that directory? also returns true.

I'm not sure that's true. Isn't the manual really saying:

Code Select Expand

> (set 'test-dir1 "C:/Program Files/programming")
"C:/Program Files/programming"
> (directory? test-dir1)
nil - no such file here
> (file? test-dir1)
nil
> (true? test-dir1)
true  - it's a string, isn't it
> (true? (file? test-dir1))
nil
>

The other issue is whether a directory or file can end with "/". I've no idea, it could be a Windows-specific thing.

[Lutz]

On Mac OS X and other UNIX 'file?' on directory names always returns 'true' regardless of the trailing slash. This is consistent with UNIX philosophy where a directory is a special file. On Win32 this should be the same and will be fixed for 10.0.2. We had a similar case for 'directory?' a few years back, where it also would fail on trailing slashes.





ps: Win32 has chosen to implement the underlying system stat() function differently from UNIX.

[DrDave]

The other issue is whether a directory or file can end with "/". I've no idea, it could be a Windows-specific thing.

More Windows inconsistencies...

On XP, navigate to any folder and attempt to rename it with a backslash or front slash on the end. The error message is

A filename cannot contain any of the following characters...

Note the term file name! So even though we are attempting to rename a folder (directory), the system tells us it is working with a file. So doesn't that sound like Windows is actually working with directories behind the scenes as special files, as UNIX does?



Now, if you have the Address bar displayed type in C:Program Files and hit enter. Get any complaints or errors, or does it navigate to that folder? Same result if you omit the trailing backslash. So, these bits of information indicate that the backslash is a separator and not actually a part of the file name, hence it makes no difference to the system when navigating to a directory if the final backslash is present or not.



Thank you, Mr. Gates and company!