A request for a new feature for the "set" command...

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Not open for further replies.
I use "SetLocal/EndLocal" a lot to avoid "polluting" the environment - and these can often be nested somewhat deeply as batch files call other batch files. However, there are times when I want to set a variable in an upper environment, or even the root environment (i. e. that of the TCMD/TCC session in which I am running the batch file), and the only way I've found to do this is the (fairly long and complicated) code sequence:

REM Where I am setting the variable:
Set Variable=...
REM Set variable as a volatile variable in the registry
Set /V Variable=%Variable

REM Where I am retrieving the variable's value:
REM Retrieve variable from registry
REM (Is this the only way????)
Set Variable=%@ExecStr[Set /V Variable]
DoWhatever with %Variable as needed...
REM Drop variable from the registry (assuming this even works)
Set /V Variable=


"/U#": Set in the environment # levels up from the current environment (may not be generally useful...)

"/U": Set in the environment one level up. (Specifying without a count - one level up - may be generally useful...)

"/T" or "/R": Set in the "Top" or "Root" environment...

I know I can avoid using SetLocal/EndLocal commands and drop the batch-file variables I no longer need at the bottom of the batch file, but doing this for all no-longer-needed variables that were used and avoiding variable conflicts with the "current" envirionment is more effort/discipline than I really want to put into this. (If setting a variable in a "lower" environment that was defined in an "upper" environment didn't "re-create" the variable in the "lower" environment (again, like other languages that have variable scoping) would do the job, but I know that this would probably "break" too much existing code and is therefore too much to ask.)

I do this regularly in C Plus Plus programs (and I am refering to environment variables) so I absolutely know it can be done...
On Tue, 02 Nov 2010 19:32:52 -0400, mathewsdw <> wrote:

|Set /V Variable=%Variable
|REM Where I am *retrieving* the variable's value:
|REM Retrieve variable from registry
|REM (Is this the only way????)
|Set Variable=%@ExecStr[Set /V Variable]

My 4UTILS plugin offers:

v:\> help @GEV
@GEV[name[,s|u|v|d]] = value of [registry] environment variable


v:\> set /v foo=bar

v:\> echo %@gev[foo,v]
|/U# - Set in the environment # levels up from the current environment (may not be generally useful...)
|/U - Set in the environment one level up. (Specifying without a *count* - one level up - may be generally useful...)

What's a "level"?

The only hierarchy of environments is the parental one ... processes inherit the
environment of their parent. And that hierarchy is not generally available to a
process or to the programmer.

My SYSUTILS plugin offers EXPORT and @PSET[] which may be helpful.

v:\> help export
EXPORT var [var [...]] (to parent 4NT/TCC)

v:\> help @pset

get[unset[set]] variable in process <pid>

returns value (get/set) or var (unset) on success, else an empty string
On Tue, 02 Nov 2010 22:51:05 -0400, Charles Dye <> wrote:

|---Quote (Originally by vefatica)---
|What's a "level"?
|---End Quote---
|SETLOCAL nesting level, I think.

OK, I see. The comments I made about EXPORT and @PSET are unrelated to
You can already do this by exporting variables in the ENDLOCAL command.
Stated simpy, Rex, thank you very much. I will note that I've been using your product(s) for many years (starting with Windows 3.1, I think), and while I read the "help" file fairly thoroghly years ago, since my eyesight has largely failed me (as I know I've mentioned in the past, I have to use the screen magnfier app and/or a large font to even use a computer) I'm reading things pretty much on an "as needed" basis and this functionality of the "EndLocal" command I was completely unaware of, and it never occurred to me that the "EndLocal" command might have those "features". Again, thanks very much Rex! The more I find out about this product, the better it is!!!!
Not open for further replies.