Let's be compatible, but I maintain that CA-Cl*pper is
fundamentally wrong here.
It's a loss in functionality, plus it results in ambiguous
file/dir interpretation, so maybe some Harbour level file
find API would come handy for those who want to get file
listing/data in an unobstructed way. Or a SET(), if we
identify some other places where there is a similar problem.
(ADIR() is based on DIRECTORY() so it won't need extra care)
Brgds,
Viktor
On 2008.02.13., at 1:23, Mindaugas Kavaliauskas wrote:
Hi,
Przemyslaw Czerpak wrote:
I know that parameter of of Directory() is passed to system
function unmodified. And the question is a little delicate (not
sure is the right english word to express what I mean), that's why
I wanted to say it on mailing list before changing behavior on SVN.
No it isn't. Clipper modifies the parameters and ads wildcards if
last character of given path is '\' or ':'. It does not make it for
'/' and in such case the results are pure OS output - the same as
in our DIRECTORY() version.
Yes, I know. After long discussion with Victor, I've made a try to
trace int 21h calls, and find out, if *.* is appended by Clipper, or
is it DOS behavior. Because it would answer the main question: is it
Clipper's behavior (need to be fixed in Harbour) or OS dependent
(should not be fixed)?
So, later on 2008-01-28 16:23 I've wrote:
> It's easy to tell: Clipper behaves the same, because this case is
> managed by Clipper DIRECTORY() function. See, below.
> ...
> I've tested what strings are passed to DOS. The same results
> in directory(".../") and directory(".../*.*") function calls
> are obtained because Clipper adds *.* if last character is
> path sepatator. So, it's not a question of platform behavior,
> it's Clipper.
This was also approved by Saulius:
> Exactly, if there is no <cDirSpec> parameter in call to DIRECTORY(),
> or string is empty, or string ends with symbol ":" or "\",
> Clipper adds "*.*"
The results will be the same as from Harbour's DIRECTORY().
It means two things:
1. code which causes such effect is part of Clipper RTL not OS.
2. the xHarbour fix was done in wrong place because it effect
all functions which uses hb_fsFind*() not only DIRECTORY()
F.e. do not check what will happen if you will execute:
FILEDELETE("C:\")
... IMHO the previous problem
with DIECTORY() for sure should be fixed. I can commit fix in few
minutes.
I share your point of view. Please, fix it.
Thanks,
Mindaugas
_______________________________________________
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
