>>Well well, guess what. Yet another function with this limitation. Found out the hard way, trying to check the infamous bug with nonexistent directories being mentioned in the DOS path, and tried with getenv("path"). It got chopped. So I got it through the Windows GUI, which is awful and completely unintuitive. You have to open explorer (file or windows, depending on the windowses' version, serious misnomer in both cases), rightclick on My Computer (which doesn't really exist, you get into a section of control panel), select advanced system settings, click Environment Variables, where you get two four-line listboxes and then scroll until you find PATH. Click Edit and you get a minimal dialog with two textboxes, not wider than 220px, where you get to edit a string of (in my case) 400 characters.
>>
>>Dos path is something I mostly forgot over the years, but now that I had to look at it... Well, the beast has a hundred lives. It's amazing how many different apps don't think the registry is appropriate as a place where they'd keep the location of their pieces, but rather add themselves to the place where it's even more error prone and subject to random changes. Drivers from Intel, SQL server tools... amazing. And that's after 22 years of registry enforcement.
>>
>>And I also have a question - how do I get the path, the whole path and nothing but the path? Can filesystem object do it, or windows scripting? Or is there a good function somewhere on Anatoliy's site?
>
>Hi Dragan,
>
>

>LOCAL m.lcSYSPATH, m.lii
>DECLARE INTEGER GetEnvironmentVariable IN kernel32.dll AS XFRX_GetEnvironmentVariable STRING lpName, STRING @ lpBuffer, INTEGER nSize
>
>m.lcSYSPATH=SPACE(1024)
>m.lii=XFRX_GetEnvironmentVariable("PATH",@m.lcSYSPATH,LEN(m.lcSYSPATH))
>IF m.lii>0
>   m.lcSYSPATH=LEFT(m.lcSYSPATH,m.lii-1)
>ENDIF
>

I knew it had to be something simple :).
Tx!