VBS, windows environment variables not resolving

philh1

Hi folks

This is a nasty problem, so it takes quite a bit of explaining. I appreciate
that many people won't read a post this long, so thanks in advance to anyone
who does.

I have run into a thorny odd problem trying to so some VBS scripting to set
environment variables in Windows. It seems to be buggering up the OS's
resolution/expansion of environment variables.

Let me explain with an example. First, go to Control Panel and create three
system environment variables.

First XHOME, set to 'c:\xyz' (this is an example after all).
Second XBIN, set to '%XHOME%\bin'
Third XLIB, set to '%XHOME%\lib'

Now, I have a bit of script which is being used by another tool to set these
sort of things during an install. Pared down for posting, the script looks
like this

Dim namedArgs
Set namedArgs = WScript.Arguments.Named

Dim varName
Dim varValue
varName = namedArgs.Item("name")
varValue = namedArgs.Item("value")

Dim shell
Set shell = WScript.CreateObject("WScript.Shell")

Dim envVars
Set envVars = shell.Environment("SYSTEM")

envVars(varName) = varValue

So, open up a command prompt and look at the variables by typing 'set X'.
Everything looks fine, and the XHOME reference is resolved okay for the
others.

Run the script,

cscript SetEnvVar.vbs /name:XHOME /value:c\xyz

(I know that this is just setting it to the original value; that's what the
other tool is asking my script to do.)

This doesn't set the enviornment variables in the process (command window)
that you run the script from, so to see the effect you have to open a new
one. So, open up a new command prompt and type 'set X' to see what has
happened. The output looks like this

XBIN=%XHOME%\bin
XHOME=c\xyz
XLIB=c\xyz\lib

Yes, you are seeing that correctly. By setting XHOME to its original value,
I have in some way confused the OS enough that it is not resolving XBIN
properly, although it does seem to be resolving XLIB.

I have spent a while on Google and Google Groups, but didn't find much.

So, has anyone any idea what to do about this? Or does anyone know a good
VB scripting forum to try?

If you are the one person who read this far (other than my Mum), then thanks
for your time.

PHiL

amen

what os are you using ?
I followed your instructions and it worked fine on Win2K
if I get a chance I will try on a WinXP later

philh1

Thanks for trying that, amen.

My machine is running
Microsoft Windows 2000 [Version 5.00.2195]

and I have also tried it on a collegaues's running
Microsoft Windows XP [Version 5.1.2600]

If you are getting the expected results (meaning the ones we would hope to get), rather than the results that I am reporting, would it be that you didn't open up a new command window after running the script? I apologise for doubting you, and I'm willing to accept that the problem is flaky and something else might be influencing it, but it is 100% reproducible on my machine and others I have tried.

PHiL

amen

running the same windows version
also opened a new command window
all seems to work

philh1

Thanks very much for trying to help, amen.

There must be something environmental in it then (oh! the irony!). I'll have to keep looking.

I appreciate your taking the time.

PHiL

Capt'n Midnight

Ruling out the stupid stuff - general enviroment variable stuff

In windows you can open two types of command prompt
start run CMD
start run COMMAND

You could also put a small batch file in the startup folder to see what they are initially - in case an app changes them
SET
PAUSE

There is also an app called SETX.EXE on the microsoft site to set global / local environment variables, by I've not seen it doing what it says on the tin

You can also try editing AUTOEXEC.NT to set variables there too

That's the lovely thing about standards - there are so many to choose from.

Hobbes

Actually your XHOME and XLIB look wrong. You have C\ instead of C:\ . Maybe the : is being stripped as a control code or something. Or this code " /value:c\xyz"


That would explain why the path won't resolve.

philh1

Hobbes:

I spotted that after the post (d'oh!), but as it happens it doesn't affect the outcome of the experiments.

As a very curious effect, which someone else from another forum pointed me at, some programs can work out the new variables just fine. For example, if I have a 'readme.txt' in the c:\xyz\bin directory (which XBIN should point to), and I execute

notepad %XBIN%\readme.txt

it won't pick up the file. However, I have another text editor that I prefer (don't we all), called Notepad2, and

notepad2 %XBIN%\readme.txt

actually does access the file! Bizarre but true!

I'm not sure where this leaves me, but it is looking less and less like I am going to find a fix for this, and instead it is more likely that a work-around will have to be found. Thanks for everyone's input all the same.

PHiL

Capt'n Midnight

Stupid question (I'm tired) does the folder c:\xyz have a space in it's name ?
If so rename it to something without a space in the folder / file name

Hobbes

Only time I've seen something funky happen is where someone managed to put in a Environment Var in lowercase.

Windows does this with system variables it sets, but you normally can't. Some programs however are case sensitive when searching for the value.

Apart from that write the output to a file/screen with "%XBIN%" see what it says.

philh1

Capt'n Midnight asked if there was a space in the name I was using for the example. There are no spaces, I was trying to keep things simple for the demonstration of the problem.

Hobbes, your suggested to "write the output to a file/screen with "%XBIN%" see what it says." I'm afraid I don't follow. I don't see how this is doing anything different than I explained in my original post. Just to be sure though, I tried

>echo %XBIN% - %XHOME% - %XLIB%
%XHOME%\bin - c:\abc - c:\abc\lib

(in the example I just ran, I changed the value of XHOME to the one shown here). I'm pretty sure that 'echo' is part of the command processor like 'dir', and unlike (for example) 'notepad' or 'notepad2', so it is using the same expansion that the 'set' command showed.

Hobbes

Could be a sorting order of the environment vars.

Other then that, only way to cause that is to set %XBIN% before setting %XHOME%