On Fri, 25 Jan 2008, Mindaugas Kavaliauskas wrote:
> >Seems to me this rather goes to down to platform behavior,
> >than being a bug in Harbour code itself. Harbour actually
> >passes down the file spec to the OS filefind call, unmodified.
> >Exact behavior for this case is also not described in detail
> >in the CA-Cl*pper NG.
It's not described but the workaround code is part of Clipper not
OS dependent behavior. We already have compatibility Clipper/DOS
code in DIRECTORY() function and hb_fsFind*() ones so IMHO adding
also support for this behavior should be done.
> 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.
You can test it pure OS output using this simple DIRECTORY() replacement
written with CT functions:
FUNCTION MYDIR(cDir,xAttr)
local aDir:={}, nAttr, cFile
if valtype(xAttr)=="C"
nAttr:=0
if "D"$xAttr
nAttr+=16
endif
endif
cFile:=fileseek(cDir,nAttr)
while !empty(cFile)
aadd(aDir,aDir)
cFile:=fileseek()
enddo
RETURN aDir
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:\")
> I guess this behavior of clipper is from DOS int 21h system API, but one
> of Harbour's purpose is to mask platform dependent behavior. Perhaps
> this case is not an exception also. Norton guide and other documentation
> never shows all possible behavior of the functions and we use tests to
> be Clipper compatible.
It's not DOS behavior. See above.
> Since directory("c:\path","d") returns an array of 1 element, my friend
> used directory("c:\path\","d") to get list of directory for years. He
> did it in Clipper, and after that he successfully did it in xHarbour.
> I've looked to xHarbour's code, they have code to mask platform
> dependent behavior:
> if ( pFileName[iNameLen-1] == OS_PATH_DELIMITER ) // '\\'
> {
> strcat(pFileName,"*.*") ; // 26/01/2004: Clipper compatibility
> }
Yes, but it should be in DIRECTORY() function not here.
> >We may try to mask these platform differences in Harbour
> >code (controlled with some more SETs), but I'd rather suggest
> >to modify the call to be more platform independent.
> I don't thing we need some set, we just need to a few lines like above
> of code to mask platform dependent behavior.
> >(f.e.:
> >*.* won't return some stuff under Linux, which would be
> >returned under DOS/Windows)
> 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.
Yes and also different wildacrds are supported, f.e.:
proc main()
? aeval(directory("harbour/source/rdd/[sd]*1.c"),{|x|qout(x[1])})
return
results:
dbf1.c
sdf1.c
delim1.c
and in this case we have real platform difference. Of course it can
be also hidden and this we can discuss but IMHO the previous problem
with DIECTORY() for sure should be fixed. I can commit fix in few
minutes.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
