Hi Sergey,

Thanks for confirming the problem and demonstrating another interesting variation. I had thought that the initial assignment x = fullpath('') showed some relationship to intermixing 1 arg usage with 2 arg usage, but your example proves that this is not necessary. However, it does appear that a prior assignment statement is a prerequisite. For example, the following does not cause any such problem:

? fullpath('','')
? fullpath('','')
? fullpath('','')
etc.

Incidentally, when I ran your test, I noticed what appears to be garbage listed to the right of the quoted string values for all of the values from x3 on. Two spaces after the closing quote, it displays m9us0023 (without quotes) on each line of output from the LIST MEMORY command. This suggests the possibility of a memory overwriting bug, which might be a helpful clue to anyone on the VFP team interested in fixing the problem.

Thanks very much for looking into it.

Mike

>Hi Michael,
>
>It's certanly a bug because FULLPATH('','') returns different results every other call. I'm not sure however which one is correct.

CLEAR
>FOR i=1 TO 8
>	STORE fullpath('','') TO ("x" + TRANSFORM(i))
>ENDFOR
>LIST MEMORY LIKE x*

>
>>Try this series of VFP commands:
>>
>>

>>x = fullpath('')
>>? fullpath('','')
>>? fullpath('','')
>>

>>
>>Note that the first result from fullpath('','') is blank (wrong!), but the second result correctly displays the current directory. All subsequent results are consistently correct, but for some reason, having immediately preceded the first invocation by the initial assignment statement that refers to fullpath('') screws up the immediately following result from fullpath called with 2 arguments. The same problem occurs for any path specified in the second argument.
>>
>>I've tested this under both VFP6SP5 and VFP7SP1, XP Pro SP1. Please confirm, do others see this nasty bug, and does it still exist in VFP8SP1?
>>
>>Mike