Setlocal equivalent

Hello world,

is there a VBScript equivalent to setting environment variables locally
in a batchfile? I wnat do to something like

setlocal
set path=<...>
set <xxx>=<yyy>
run_my_app
endlocal

but I'd like to use VBScript (.vbs) rather than a batchfile.

Jens

Alexander
Tue May 09 04:53:40 CDT 2006

Jens Lenge schrieb:
> Hello world,
>
> is there a VBScript equivalent to setting environment variables locally
> in a batchfile? I wnat do to something like
>
> setlocal
> set path=<...>
> set <xxx>=<yyy>
> run_my_app
> endlocal
>
> but I'd like to use VBScript (.vbs) rather than a batchfile.

if you run a script you get a copy of all environment variables of the
calling process, and you can change or add these environment variables
as you like.
Those variables you change/add in the "Process" WshEnv-Object only
affect your local script-scope, the will 'die' when
the script terminates, so this is the equivalent to
SETLOCAL.
Those variables you change/add in the "System"-WshEnv-Object
affect the 'master environment' itself and persist when the script
ends.


'#
'# add a volatile and persistent env-variables
'#

Set WshShell = WScript.CreateObject("WScript.Shell")
Set WshProcEnv = WshShell.Environment("PROCESS")
Set WshSysEnv = WshShell.Environment("SYSTEM")
WshProcEnv("SOME_SILLY_PROC_TEST_VAR") = "volatile value"
WshSysEnv("SOME_SILLY_SYSTEM_TEST_VAR") = "persistent value"

'Then open cmd.exe manually and see the result by typing:
SET SOME_SILLY

MfG,
Alex

Jens
Tue May 09 08:44:11 CDT 2006

Thanks for the info.
Now that I know what to look for...
I found in the manuals that there 4 environment spaces: System, User,
Process, Volatile

I assume that...
a) "System" ist persistent and global for all users and all processes
b) "User" is persistent, limited to the current user, and global for
all processes launched by this user
c) "Process" is non-persistent and limited to the current process and
all processes launched by the current process

Are my assumptions correct?
But what the heck is "Volatile"?

Jens

Michael
Tue May 09 18:30:28 CDT 2006

>> But what the heck is "Volatile"?
>
> Volatile means 'flüchtig', probably more volatile then 'process'
> could have an intrinsic decay time of three mouse-clicks (???)

Volatile environment variables exist only during a logon session but persist
across processes within that logon session.

--
Michael Harris
Microsoft MVP Scripting

Alexander
Wed May 10 07:56:53 CDT 2006

Michael Harris (MVP) schrieb:

>>> But what the heck is "Volatile"?
>> Volatile means 'flüchtig', probably more volatile then 'process'
>> could have an intrinsic decay time of three mouse-clicks (???)
>
> Volatile environment variables exist only during a logon session but persist
> across processes within that logon session.
>

Hi MH!

Thanks very much for clarifying :-)
To my surprise changing SYSTEM-vars by script is persisting even
across reboots a/o sessions.


MfG,
Alex

Jens
Wed May 10 11:30:50 CDT 2006

Also thanks from me. :o)

BTW, why were you surprised? IMO that is how the SYSTEM space is
supposed to work (as I assumed in my previous posting). Am I wrong?

Michael
Wed May 10 18:56:34 CDT 2006


> Thanks very much for clarifying :-)
> To my surprise changing SYSTEM-vars by script is persisting even
> across reboots a/o sessions.


Just as the SYSTEM environment variables are meant to behave WRT to
persistence across same or different user (same machine) logon sessions and
across machine reboots.

VOLATILE is like SYSTEM cross process (parent/child, child/parent, or
sibling/sibling or event unrelated) except only within an active user logon
session. Any logoff/logon sequence starts VOLATILE over from scratch
regardless of same or different user logon or any intervening reboot.

Think of USER as private per user and persistent, SYSTEM as public (given
user read/write permissions to relevant parts of SYSTEM some of which need
admin permissions) and persistent, and VOLATILE as a hybrid of USER and
SYSTEM less the persistence and permissions since it only lives with a given
user logon session. All three of these are also 2-way between parent/child
(executable) processes because they are persistent (at least within a logon
session for the least persistent VOLATILE).

The PROCESS environment is a merge of at least USER+SYSTEM (and current
state of VOLATILE) plus anything added by the a preceding (or the current)
parent to PROCESS, always transient, and passed as a one way copy from
parent to child. Any PROCESS environment change made by a child is not
exposed to the parent but is to a grandchild that gets a copy of the PROCESS
environent of the preceding child (of the root parent) passed to the
grandchild (assume I am the process in the middle of a
parent/child/grandchild tree - I am my parent's child and the parent of my
child who is my parent's grandchild).

--
Michael Harris
Microsoft MVP Scripting

Alexander
Thu May 11 03:46:27 CDT 2006

Jens Lenge schrieb:

> Also thanks from me. :o)
>
> BTW, why were you surprised? IMO that is how the SYSTEM space is
> supposed to work (as I assumed in my previous posting). Am I wrong?
>

Not at all.
I think to remember that some years ago everybody said
a script can never ever change environment variables that persist
the script's lifetime or even the user-session.

The common bottom line was that u need tools like winset or xset or
something. Maybe it only applies for the Windows 9x-line.

MfG,
Alex