refreshing environment variables on a console

[Pedro CR]

hi

i am trying to write a bath file that first calls a wsh script that sets an
environment variable and later in the same batch file that variable is
needed as an argument to a program that is called.
the problem is that, although the script sets the envirnment variable
correctly, it is not available to the console who called the script. I
assume that the problem is that the console does not refresh its environment
variables, because if I open a new console, the environment variable is
there.

What I wanted to know was if there a way to force the console to reload the
environment variables while processing the batch file, and making the new
environment variable visible to the console who ran it and batch file being
processed in that console.

thanks in advance
pedro

 

[Pegasus \(MVP\)]

hi

i am trying to write a bath file that first calls a wsh script that sets an
environment variable and later in the same batch file that variable is
needed as an argument to a program that is called.
the problem is that, although the script sets the envirnment variable
correctly, it is not available to the console who called the script. I
assume that the problem is that the console does not refresh its environment
variables, because if I open a new console, the environment variable is
there.

What I wanted to know was if there a way to force the console to reload the
environment variables while processing the batch file, and making the new
environment variable visible to the console who ran it and batch file being
processed in that console.

thanks in advance
pedro

This is not a problem about "refreshing"; it is a problem about parent
and child processes, and who inherits what.

Assume that you have a command process. We call it the "parent"
process. In this process your batch file calls a whs script. That script
runs in a "child" process. It inherits the environment from the parent
process. Any change made to the child environment is visible to the
child process only. When the child process terminates then these
changes are lost.

If you wish to communicate from a child process back to a parent
process then you must do it like this:

@echo off
wsh . . .
call "%temp%\SetEnv.bat"

The wsh process must (among other things) generate the auxiliary
batch file "%temp%\SetEnv.bat". It will have a single command
of the form

set SomeEnvVar=SomeValue

Alternatively, you could do it like so:

@echo off
for /F %%a in ('wsh ...') do set SomeEnvVar=%%a

In this case wsh must generate one single line of console
output, namely "SomeValue" (without the quotes) so that
the "for" command can pick it up.

 

[Al Dunbar]

This is not a problem about "refreshing"; it is a problem about parent
and child processes, and who inherits what.

Assume that you have a command process. We call it the "parent"
process. In this process your batch file calls a whs script. That script
runs in a "child" process. It inherits the environment from the parent
process. Any change made to the child environment is visible to the
child process only. When the child process terminates then these
changes are lost.

If you wish to communicate from a child process back to a parent
process then you must do it like this:

@echo off
wsh . . .
call "%temp%\SetEnv.bat"

The wsh process must (among other things) generate the auxiliary
batch file "%temp%\SetEnv.bat". It will have a single command
of the form

set SomeEnvVar=SomeValue

Alternatively, you could do it like so:

@echo off
for /F %%a in ('wsh ...') do set SomeEnvVar=%%a

In this case wsh must generate one single line of console
output, namely "SomeValue" (without the quotes) so that
the "for" command can pick it up.

It seems that the OP has not simply set the environment variable in the new
child process, but actually made the change in the system variables space.
Note that he says that a new CMD process actually has the new value for this
variable.

But, as you say, a process inherits the environment of the parent (and, I
suspect, this includes inheriting a copy of the system environment at that
time). So the process that inherited the pre-variable-setting environment is
not going to have its copy of that environment modified by the simple act of
a child process modifying the system environment.

Your workaround suggestions are valuable, however, I would suggest to the OP
that he reconsider his overall application, because these kinds of
workarounds can get messy and difficult to track.

One way would be to migrate the batch components to WSH, and keep all
"environmental" issues in the registry.

/Al

 

[Todd Vargo]

:

Your workaround suggestions are valuable, however, I would suggest to the OP
that he reconsider his overall application, because these kinds of
workarounds can get messy and difficult to track.

One way would be to migrate the batch components to WSH, and keep all
"environmental" issues in the registry.

For all intents and purposes, storage in the registry is equivilent to
storage in a transient batch file. Keeping track is not really that
difficult once one learns how things operate.

FWIW, I had a more elementary take on the OP's issue. From the OP's
statement, "it is not available to the console who called the script", I
take that as meaning the variable is not set when batch has ended. The
problem may well be the parent/child issue, but it would have been nice to
see the code in question to remove all doubt.