FiveTech Support Forums

hua wrote:Does this issue still exist in latest xHarbour?

TIA

Yes.

EMG

@Verhoven - thanks for the reply but I'm not looking for a workaround. I was hoping that the bug is squashed so I don't have to alway remember not to upgrade my xHarbour

@Enrico - thanks for the feedback. That's unfortunate to hear

I think that the solution i wrote is not workaround. Why?:
This code is inexact and inconsistent:
copy to (cTmp)
? file(cTmp+".dbf")
Because in the firt line you refer a file only using the variable cTmp and in the second line you add the extension ".dbf". Did you try with "? file(cTmp)".
And because in its first line, working under windows or DOS, you can generate a file called cTmp+".dbf" or even cTmp+".DBF" because the reference to both names is the same but not in UNIX.
In UNIX is not the same a file called cTmp+".dbf" than a file with name cTmp+".DBF"

So it is much more accurate to say the exact name of the file you want to generate and not to leave to the compiler the interpretation of the name you want. This behavior you call a "bug" force you to be more accurate.
Clipper was designed for DOS and xHarbour was for UNIX, DOS and windows this is the reason why i think it can not be that all the instructions must work excatly in clipper than in xHarbour bacause they can not be the same for all the O.S.

Verhoven wrote:Try with this:

In your code use:
copy to (cTmp+".dbf")

instead of:
copy to (cTmp)

Just tried: no change.

EMG

Verhoven wrote:I think that the solution i wrote is not workaround. Why?:
This code is inexact and inconsistent:
copy to (cTmp)
? file(cTmp+".dbf")
Because in the firt line you refer a file only using the variable cTmp and in the second line you add the extension ".dbf". Did you try with "? file(cTmp)".

Why would I need to when Clipper documentation for COPY TO clearly states "TO <xcFile> specifies the name of the target file. The filename can be specified either as a literal filename or as a character expression enclosed in parentheses. If SDF or DELIMITED is specified, (.txt) is the default extension. Otherwise, (.dbf) is the default extension."?

And because in its first line, working under windows or DOS, you can generate a file called cTmp+".dbf" or even cTmp+".DBF" because the reference to both names is the same but not in UNIX. In UNIX is not the same a file called cTmp+".dbf" than a file with name cTmp+".DBF"

So it is much more accurate to say the exact name of the file you want to generate and not to leave to the compiler the interpretation of the name you want. This behavior you call a "bug" force you to be more accurate.

Yes I'm aware that linux uses a case-sensitive filesystem but that is irrelevant to me because I don't program on linux. You are aware that the bug that I was pointing out is with regard to COPY TO not following path in SET DEFAULT not something to do with filename?

Someone on xHarbour's NG pointed out another command that doesn't respect the path in SET DEFAULT can't remember what though