>> and you've gone and made a horrid mistake, here, fishlady - you've gone and a$$umed that the current directory is the application directory!!!
>
>Yep. Correct enough. But, then CURDIR() has that same problem, no?
>

Yep - all I've done is explicitly stated the assumption. It makes it easier when the next idjit in line can't figger out why she's no work like they think it should. If what you want is the current folder, FULLPATH(CURDIR()) is a little more bulletproof than SYS(5) + SYS(2003). It also gets around the really bonehead errors like assuming that SYS(5) will return a 2 character string where the last character is a :

>> GETFILE() can be used with FULLPATH() and then tested with FULLPATH(Blah, blah, stupid directory) to make sure the idiot end-user didn't make use of the power handed to them by the immensely lazy programmer who was lacking in neurochemical energy expenditure when they decided that GETFILE() was just the ticket. It was - a clear ticket to an invite to off.ramp if they really want to know what I think of the bad habit of using GETFILE() incorrectly...I can't use the requisite vocabulary here.
>
>The point that I'm sure you are trying to make in this paragraph is being utterly lost to me. But, it's only important if it helps the originator of the post.

If the idea is to GETFILE() and then test to make sure that GETFILE() came back in some other directory than the current directory, you can use the FULLPATH("F:FOO") to resolve F:FOO to the absolute pathname associated with F:FOO; the reference, being non-absolute, is relative to the current folder on the referenced drive, and you need to convert it to an absolute path reference.