China DOS Union

I set some variables with SET in the BAT file, but as soon as the BAT ends, those variable values disappear. What method can be used to make the variable values remain and be usable even after the BAT ends?

Using JScript or VBScript in batch processing to set variables. For example:

//test.js
var shell
shell = WScript.CreateObject("WScript.Shell")
shell.Environment("System").Item("DEVMGR_SHOW_NONPRESENT_DEVICES")='1'

If you don't specifically cancel the set environment variables in the batch processing, they will always exist originally, and there's no need to rack your brains about this. Unless you restart the machine.

What you said upstairs is incorrect. In batch processing, the environment variables set are only effective in one cmd process. If the cmd process is closed, the variables will disappear. The owner must have directly double - clicked to execute the batch processing, and after execution, the corresponding cmd process is directly closed. Even if it is not closed, the environment variables set by the batch processing are only effective in the cmd environment in which it runs, not globally effective. Just try it! First, open a cmd window, set an environment variable, and then open another cmd window to check if there is the corresponding environment variable.

CMD?!
I'm sorry, I only consider the pure DOS environment.

By the way, I want to tell you my view all the time: Now our DOS forum is getting less pure. Many problems are actually under Windows, but they are posted to the "DOS Problem Solving Room". There are many such examples, and you can find some by flipping a few pages later. If I were a moderator, I would have moved them long ago. Of course, there are some problems that belong to a relatively low level and have little to do with the operating system, but the forum doesn't have a special section for this. Maybe it's because there are more people in the "Difficult Problems Solving Room", so they are posted here. Hehe

In addition, I haven't seen Xiao Ke for a long time. Come on, let me give you a kiss Hehehe...

It can't be so absolute. Although cmd is different from DOS, but our purpose is to use the computer to serve us better. Why be too persistent? After all, there are not many people using pure DOS for work now. The applications in the cmd environment are far more than those in pure DOS. Besides, at the batch processing level, there is no essential difference between the two.

Re 024024l:

The situations where modifications to environment variables become invalid after the program ends are mainly of the following types:

1. Under the COMMAND of DOS/9x/NTs, using %comspec% in a batch script to call another program and subroutine, and modifying variables in it. After the %comspec% call ends, this modification will be invalid;

Solution: Save the environment variables in it to a temporary batch file before the %comspec% call ends, and then run this batch file after the end to reset the variables.

Example:
%comspec% /c %0 : subroutin
%temp%\_setlocal.bat with the _setlocal.bat
goto end

:subroutin
set local=var1
echo set local=%local% > %temp%\_setlocal.bat
goto end

:end

2. Under the CMD of NTs, using the setlocal environment variable localization command in a batch script. From then on, until endlocal is encountered or the batch script ends, all modifications to environment variables during this period will be invalid afterwards;

Solution: Before the batch script ends, use the enlocal command and combine with the environment variable setting statement to run;

Example:
setlocal
set local=var1
enlocal & set local=%local%

3. In the COMMND/CMD under Win, modifications to environment variables usually only take effect in the current command line environment. It will not affect the system globally or all subsequent command line environments;

Solution: Use the enhanced tool setx device variable on the Windows98 installation disk.

Example:
setx local=var1

Re Climbing:

The differences and connections among these environments such as MSDOS6.22/7.10/COMAND@Win9x/COMMAND@WinXP/CMD@WinXP are extremely complex. Their impact on batch scripts is also immeasurable. It directly leads to after writing batch scripts, and I must repeatedly verify its compatibility in various environments. Untested environments will never easily be placed in its runnable environments, even if they are the same COMMAND or CMD.

Originally posted by Climbing at 2006-3-23 08:24 PM:
It can't be so absolute. Although cmd is different from DOS, our purpose is to use the computer to serve us better. Why be too persistent? After all, there are not many people working with pure DOS now, and the programs in the cmd environment...

I agree with this statement!

Originally posted by Climbing at 2006-3-23 20:24:
It can't be so absolute. Although cmd is different from DOS, but our purpose is to use the computer to serve us better. Why be too persistent? After all, there are not many people working with pure DOS now, and the library in the cmd environment...

What I said is not about this post, just thinking of it and just saying a few words. You can go and see the following few posts, and you will know that some problems have nothing to do with the command line. Many people apply the concepts under Windows to DOS.

The simplest method:
At the end of the batch processing, write the assignment statement of the variable you want to save into a batch processing file, and then modify your registry to make the batch processing file execute first every time CMD is started. For example, add a line at the end of your batch processing:
set myvar=%var% >> c:\mybat.bat
Then modify the AutoRun value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor to c:\mybat.bat
In this way, when you run the batch processing or CMD, mybat.bat will be executed automatically.
If you don't want to modify the registry, you can also create a shortcut on the desktop. In the command line, enter:
cmd /k c:\mybat.bat
In the future, as long as you execute the batch processing through this shortcut, the value of the variable can be guaranteed.

The DOS in the site is a bit impure, but everything is changing, and we can't always stay in one place. What we hope is just to exert our maximum ability to support and use this evergreen system --- DOS