Declined Loop on environment variable names?
- Thread starter vefatica
- Start date
I know ... a thread from a long, long time ago (had quite some cobwebs on it), but I stumbled upon this one while randomly browsing the "wishlist".
I think it *is* possible (at least, if I understood the original problem correctly; else I'll leave it for the spiders again) :
SET (without the "usual suspects"):
AA=1
AB=3
AC=12
OS=Windows_NT
QQ=44
xxx=AB
Code:
set | for %x in (@con) if "%@word["=",0,%x]" =~ "[a-z][a-z]" set /a som+=%@word["=",1,%x]Output:
[C:\Temp\ff\pu\TCC_20.0.17]set | for %x in (@con) if "%@word["=",0,%x]" =~ "[a-z][a-z]" set /a som+=%@word["=",1,%x]
1
4
16
16
60
[C:\Temp\ff\pu\TCC_20.0.17]
=~ "[a-z][a-z]" is a regular expession condition: if variable consists of exactly two (a-z) case-insenitive characters, it's OK.
%OS% is one of those variables, but the resulting text won't get added ( 16 --> 16 )
If you want to "export" %som%, use set |! for .... (I recently learned from vefatica ;-)
Oh, by the way: I started by writing this in CMD first (old habits die hard ...).
Turns out to be possible in a single line, too.
It requires setlocal enabledelayedexpansion.
So:
- Start a new CMD with parameter /V to have delayed expansion enabled right away. Reasons why:
1) No one can type enabledelayedexpansion without making errors and
2) SETLOCAL ADSCXPPLAQWJKLKWQFFSFA (see what I mean?) is only valid inside batchfiles.
- Create environment variables:
Start processing:
Result: som=97
The "trick":
Problem with handling variables like AA is, that when you "access" them, they will get parsed and the value will be returned instead of the key itself.
To work around that, I created a helping variable (must be a better word for this ??) and put a "_"in front, so now they won't get parsed. Every manipulation (comparison, substring,..) has to use the same "_" to make it work. That's it.
Turns out to be possible in a single line, too.
It requires setlocal enabledelayedexpansion.
So:
- Start a new CMD with parameter /V to have delayed expansion enabled right away. Reasons why:
1) No one can type enabledelayedexpansion without making errors and
2) SETLOCAL ADSCXPPLAQWJKLKWQFFSFA (see what I mean?) is only valid inside batchfiles.
Code:
CMD /v
Code:
set som=
set AA=12
set AB=22
set AC=54
set QQQ=4
set ZZ=9Start processing:
Code:
for /f "usebackq tokens=1,2 delims==" %X in (`set`) DO set W=_%X&if "!W:~0,3!" == "_%X" set /a som+=%Y
set somResult: som=97
The "trick":
Problem with handling variables like AA is, that when you "access" them, they will get parsed and the value will be returned instead of the key itself.
To work around that, I created a helping variable (must be a better word for this ??) and put a "_"in front, so now they won't get parsed. Every manipulation (comparison, substring,..) has to use the same "_" to make it work. That's it.
Last edited:
In object rexx, this is `do v over (stem)`.
It would suppose that you had an enumerable list, a page of environment, or something like an inifile[section] that you could pull off environments.
The windows environment is a rather strange thing. None of the active ones are in the registry, so you have to walk around the memory to get, say the parent memory. There are system created variables that do not come from the registry itself, but are set by the system on sysinit. For example, the machinename comes from a different place to the username.
We had all sorts of fun hunting down the appropriate utilities needed to set the master registry in BartPE.
Speed is not itself a main concern. I was running a start-stop computer program under 4dos, which called rexx scripts and these created UBASIC scripts and set file-system semaphores etc, but the only lump of code that was executed any large number of times was a couple of lines in UBASIC. If something is going to be executed hundreds of millions of time, you bum the code there, but a few thousand times no. Generally, the code is there as a fail-safe, to save you having to tinker around in the core of it.
On the other hand if it's doing stuff in files at core speeds, there are such things as ramdisks, even in Windows 7. I currently run the x86 vers with a 5 GB ramdisk, but in the days of W2K, i used a 64 MB ram disk to do things.
One thing useful, is that you can store and maintain a registry setting for your own proggies, made from a master batch file. So what you do is have hklm\software\wendy\paths for all of your various paths, and then drag these out when you compile your batches or run your batch, so you could have ramdisk=r:\ and set this in the master setup batch, and anything that needs a ramdisk gets the location from the local registry.
The other thing one might do is to pipe the environment off to a stack, and then pull items off the stack. Regina rexx has a stack program, for example. Even under MS-DOS i used a stack driver from Quercus rexx.
It would suppose that you had an enumerable list, a page of environment, or something like an inifile[section] that you could pull off environments.
The windows environment is a rather strange thing. None of the active ones are in the registry, so you have to walk around the memory to get, say the parent memory. There are system created variables that do not come from the registry itself, but are set by the system on sysinit. For example, the machinename comes from a different place to the username.
We had all sorts of fun hunting down the appropriate utilities needed to set the master registry in BartPE.
Speed is not itself a main concern. I was running a start-stop computer program under 4dos, which called rexx scripts and these created UBASIC scripts and set file-system semaphores etc, but the only lump of code that was executed any large number of times was a couple of lines in UBASIC. If something is going to be executed hundreds of millions of time, you bum the code there, but a few thousand times no. Generally, the code is there as a fail-safe, to save you having to tinker around in the core of it.
On the other hand if it's doing stuff in files at core speeds, there are such things as ramdisks, even in Windows 7. I currently run the x86 vers with a 5 GB ramdisk, but in the days of W2K, i used a 64 MB ram disk to do things.
One thing useful, is that you can store and maintain a registry setting for your own proggies, made from a master batch file. So what you do is have hklm\software\wendy\paths for all of your various paths, and then drag these out when you compile your batches or run your batch, so you could have ramdisk=r:\ and set this in the master setup batch, and anything that needs a ramdisk gets the location from the local registry.
The other thing one might do is to pipe the environment off to a stack, and then pull items off the stack. Regina rexx has a stack program, for example. Even under MS-DOS i used a stack driver from Quercus rexx.
Similar threads
