Hi Paul,
This is fine, but DIR command will probably do its own
logic when it comes to processing and modifying passed
filenames.
I personally _always_ append an ending slash manually
to avoid any confusion or to rely on the logic of the
underlying systems, because:
"C:\entry" could as well mean file C:\entry itself or
the content of C:\entry, depending on the situation,
subsystem or tools actually used.
"C:\entry\" however _always_ means the content of the
folder named "entry".
For a tool which is really confused about these matters,
it's enough to see DOS/WIN COPY, which goes as far as
_asking_ the user what was exactly meant.
So, if Harbour would automagically append an ending slash,
how would I be able to get the file data of one sole
entry, like "C:\entry" where "entry" is a single file in
the C: root?
In case of DIRECTORY() we simply cannot be sure if the
ending backslash is intentionally added, or it is just the
underlying subsystems' side-effect. And even if it were
added by DIRECTORY() I'd rather consider it a bug, or
at least not something portable, or universally correct.
This would then fall (IMO) into the same category when
functions are automatically changing the casing of a filename.
All these situations are handled with SETs in Harbour,
just because there are ppl who favour strict MS-DOS
compatibility over portability and vice versa. (it is
usually a process I guess, where these SETs are eventually
turned off, when application code is corrected to avoid
these gotchas.)
Brgds,
Viktor
On 2008.01.26., at 14:32, Paul Tucker wrote:
Victor,
MK>> I've just finished my test on linux. I do not have Harbour under
??>> linux, but I've tried to analyze opendir() system call.
opendir("/
??>> path/") gives listing of folder, so, I guess directory("/path/")
??>> will also (but it can depend on our implementation). This made
me a
??>> stronger feeling we must hide platform dependent behavior under
??>> windows.
??>> So, if DOS and Linux version for directory(".../") gives file
list
??>> and the Clipper also, I found it to be enough reason to hide
??>> platform behavior under windows by adding a few lines of code.
??>> BTW, "*" will work on both windows and Linux, but it's not the
case,
??>> because in linux we need to pass path only to opendir() function.
??>> File mask filtering is done later by our code.
SV> Maybe this works, but it's easy to find a parameter which
SV> would behave differently depending on the platform, enough
SV> to think about casing, drive letters, or any other speciality
SV> (like special chars).
...
SV> I still think it's not Harbour's job, to present a "virtual FS"
SV> with fully MS-DOS compatible rules. Or even if want such thing,
SV> it should be an option.
If you open a command window under xp and vista, DIR mydir and DIR
mydir\ both do the same thing. Ditto if you paste those into an
explorer window.
If you expect dir c:\mydir to show one entry, then you're asking for
the contents of c:\ and just need to append a wild-card. (at least
at the command prompt, and I would think in Harbour code too)
Random thoughts.
Paul
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
