>Hi George,
>
>>>>Not if the file's in the current working directory.
>>>
>>>True. But if it's not you get an OLE error and if it is you may as well have used CURDIR() in the first place :-)
>>
>>Not really, wherever the application is started from is the working directory. Plus Windows will search the path.
>
>True - but I think we've wandered down a side-alley on this one. My orginal need was to convert the short DOS path returned by SYS(2023) to the long path name. I thought you were suggesting that something like:
>

>oFolder = oFSO.GetFolder(SYS(2023))
>lcLongPath = oFolder.Path
>

>would achieve this. But if a short name is passed in then oFolder.Path still returns the same as oFolder.ShortPath. Maybe a shortcoming in the FSO but, IAE, it doesn't do the job....
>
>>Any web page running either jscript or vbscript will require it. Further, Windows since 2K has a habit of repairing itself. So if a file is required, you've got to jump through major hoops to get out permanantly.
>>
>
>You're right in that it's not that simple to remove in newer OSs - but the fact remains that we encounter systems where, rightly or wrongly, wisely or foolishly, admins have disabled scripting.
>
>>Lastly, do they delete cscript.exe as well? How about command.com?:-)
>
>Wouldn't be a bit surprised. Paranoia runs deep in some of these places - NTLDR would go if they had their way :-}
>
>>GETENV() with either TMP or TEMP will return the temporary file path name, but, like before, it will be the short path.
>
>Don't these just get read in from the DOS environmental settings? In that case they presumably return whatever they find. Oh - and I see I was wrong about the GetTempFile() API call possibly returning an invalid path - docs say that if will only use TMP or TEMP values if they represent a valid directory..
>
>Regards,

Viv,

All in all it ain't easy, is it?