directory? vs. file? on WIN32

Machine-specific discussion
Unix, Linux, OS X, OS/2, Windows, ..?
Locked
DrDave
Posts: 126
Joined: Wed May 21, 2008 2:47 pm

directory? vs. file? on WIN32

Post by DrDave »

Why is there this subtle difference in results?

Code: Select all

(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.
...it is better to first strive for clarity and correctness and to make programs efficient only if really needed.
"Getting Started with Erlang" version 5.6.2

newBert
Posts: 156
Joined: Fri Oct 28, 2005 5:33 pm
Location: France

Post by newBert »

Why have I got these results on my computer ?

Code: Select all

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
>
BertrandnewLISP v.10.7.6 64-bit on Linux (Linux Mint 20.1)

cormullion
Posts: 2038
Joined: Tue Nov 29, 2005 8:28 pm
Location: latiitude 50N longitude 3W
Contact:

Re: directory? vs. file? on WIN32

Post by cormullion »

DrDave wrote: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 all

> (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
Posts: 5289
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California
Contact:

Post by 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
Posts: 126
Joined: Wed May 21, 2008 2:47 pm

Re: directory? vs. file? on WIN32

Post by DrDave »

cormullion wrote: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!
...it is better to first strive for clarity and correctness and to make programs efficient only if really needed.
"Getting Started with Erlang" version 5.6.2

Locked