>>Try
>>
>>set default to (sys(5)) should work fine.
>
>I'd hoped this one had died a death - set default to sys(5) works fine for me from the command line, within a program and within a class. Did you test to see whether it worked for you - maybe the change has come in some later version of VfP, but in all of my testing of the original problems, I could not get any errors generated.

The solution to the problem is to ensure that all paths specified in the SET PATH statement use the Short pathname - this is the DOS-compatible pathname, which can be extreacted for the path at runtime by parsing the return of SET('PATH') into discrete paths, and then resolving the Short path name using either the Windows API or the Scripting.FileSystemObject from WSH. The short name never contains any spaces, and so the real cause of the problem, which is the run-time invocation of the command line parser via macro-expansion, is eradicated. By default, VFP's CLI treats unencapsulated spaces as delimiter characters, which is why

cPathName = "C:\My Path Name With Spaces In It"
SET PATH TO &cPathName

screws the pooch, but

cPathName = "C:\My Path Name With Spaces In It"
oFSO = CreateObject("Scripting.FileSystemObject")
oFolder = oFSO.GetFolder(cPathName)
cPathName = oFolder.ShortName
SET PATH TO &cPathName

works fine.

The problem is not macro-expansion vs evaluation vs name resolution, it's the behavior of the VFP CLI parsing a string containing names which may contain delimiter characters; name resolution (implicit in the use of expressions in the statement, or invoked directly using parenthetic encapsulation (the problem here is that only one name resolution can occur in the argument string of the SET PATH, and that may only resolve a single path)) treats the entire string as a name and doesn't try to parse it.

If you always convert all paths in the SET PATH string to their short form, the problem of embedded spaces and parsing the statement with macro-expansion goes away. Alternatively, you can quote-encapsulate those parts of the SET PATH statement that contain embedded delimiters explicitly in the string, so that the parser treats them as a single parameter. Not taking the necessary steps to properly handle the use of macro-expansion is the result of the programmer not understanding what macro-expansion does and how names behave in the VFP environment.

BTW, you need to resolve the short path name at runtime, as it may be different from system to system depending on the order in which files and folders are created, and the system settings for converting long paths to short paths. Use of the WinAPI GetShortPathName() function or the FSO takes into account current system settings. I'd recommend the use of explicit full paths rather than relative paths if relative paths may contain embedded delimiters.