5 replies to this topic

[Holger]

This bug-info I got from an Autoit-User (Carsten )
And I could reproduce it under Windows'95, 98 and Me with this small test script:

$result = EnvSet ("test", "c:\data\xyz;c:\data\1")
Msgbox(0, "envset", $result & @LF & @error)

$result = EnvSet ("path", "%path%;c:\zfiles\bin")
Msgbox(0, "envset", $result & @LF & @error)

EnvUpdate()

Run(@ComSpec & " /c set >c:\Temp\set.txt")

Msgbox(0, "Envget", EnvGet("winbootdir"))

The return values are both "1" and @error is set to "0".
have no idea what could be the problem cause EnvGet is running fine
Regards
Holger

[Holger]

BTW: It also doesn't work with Autoit2
(my small test script:
SetEnv, Test, Just a Test
RunWait, %COMSPEC% /C set > C:\\temp\\set.txt
)

Does somebody has an idea what it could be?

Seems to/could be a problem with Run/RunWait and getting the environment under Win9x...
Cause with EnvGet() you get the variables

Regards
Holger

[Confuzzled]

EnvSet help file says:
Return Value
Success: Returns not 0. <<< this could be more clearly explained
Failure: Returns 0.

I get (on a Win98SE virtual machine) three message boxes with 1,0 and 1,0 and C:\WINDOWS respectively with AutoIT3 latest 3.2 release.

Edited by Confuzzled, 13 August 2006 - 08:44 AM.

[nitro322]

Is this bug still under investigation? I found a separate but similar issue using EnvSet() under Win9x to update the PATH variable. Simple test case:

$pathold = envget('path')
envset('path', @scriptdir & ';' & envget('path'))
$pathnew = envget('path')
msgbox(0, 'Test', 'pathold = ' & $pathold & @CRLF & 'pathnew = ' & $pathnew)
runwait(@comspec & ' /k echo %path%')

As I explained in this thread, the msgbox shows the correct information, but the @comspec command shows the old path. So, while EnvSet() and EnvGet() seem to work properly, command.com does not inherit the updated PATH variable when spawned from the AutoIt script. This is wreaking havoc on my poor script.

Any news or updates to this issue? Thanks.

[Selmak]

To which I'd add that EnvSet() and EnvUpdate() don't work with some of the predefined variables in NT/XP.

EnvUpdate() also (AFAICS) ignores the Volatile Environment registry section.

This may be unavoidable, I guess, if the system protects the predetermined values in some way.

[IIsi50MHz]

I came across this topic from a thread on the MSFN.org thread for Universal Extractor and replied there:
http://www.msfn.org/board/Universal-Extrac...467#entry742467

Summary:
{nitro322}AutoIt and Windows 9x seem to have a whole lot of difficulty agreeing on the PATH{/nitro322}

{shaddam}
i also tried to pindown the problem....
'winset.exe' works... for instance, if start uniextractor with this bat:
start.bat
''winset path2=%path%;c:\uniextractor;c:\uniextractor\bin
uniextractor.exe
winset path=%path2%''
... the path variable is recovered succesful & not destroyed (but uniextractor is also not working.... :/)
{/shaddam}

{IIsi 50MHz}
Avoid using "start" as a batch file name because it can conflict with START.EXE. The second line of your batch file should be "start /wait uniextractor.exe".

I am able to consistently preserve the PATH variable on Win98SE, regardless of AutoIt error state, by running it from a batch file set to hide its window and output:

univextr.bat:
@SET PATH1=%PATH%
@START /wait Uniextract %1 %2 %3 %4 %5 %6 %7 %8 %9
@WINSET PATH=%PATH1%
@SET PATH1=
{/IIsi 50MHz}

Given that this technique works when launching the AutoIt-based Universal Extractor directly and using the open script's window as a drop-target for files, perhaps the generic way around the problem (not specific to UE) is to wrap one instance of AutoIt inside another. Just as the batch file wraps AutoIt/UE, waits for it to exit, and the cleans up...perhaps AutoIt could save a local copy of the %PATH% with "envget('path')", launch the second instance of AutoIt with the main script, wait for that second instance to close, and then clean up with winset.exe.

(The %1...%9 aren't really necessary, but let the batch file function as a short-names-only drop handler of a sort)