"I have a need to see the envvars whose names are exactly two characters long. Can I do that with SET alone?
SET question
- Thread starter vefatica
- Start date
Vince, I certainly could be wrong in that I don't think there's any "command" that will do that, but doing what you want to do doesn't take all that much code, either. Specifically,
gets the job done, and it isn't all that long or complicated (and can obviously be made a into .btm file that can either be "Call"ed or "@ExedArray"'d, or invoked by an Alias if you want to run it from the command line, and the number of characters long that you want a variable name to be is a parameter that "defaults" to 2 in the above code to boot).
- Dan
Code:
@Echo Off
SetLocal
UnsetArray /Q EnvVars
SetArray EnvVars[64]
Echo >NUL: %@ExecArray[EnvVars,Set]
Set I=0
Do While %I LT %_ExecArray
If %@Len[%@Left[%@Index[%EnvVars[%I],=],%EnvVars[%I]]] == %@If["%1" == "", 2,%1] ^
@Echo %EnvVars[%I]
Set /A I+=1
EndDo
UnsetArray /Q EnvVars
EndLocal
Quit 0- Dan
Or, if you don't mind using an external:
(Find lines beginning with any character, followed by any character other than the equals sign, followed by an equals sign.)
Code:
set | grep "^.[^=]="Charles,
I truly am laughing as I type this.:) Your answer is so correct and so obvious. However I will note that (somewhat sadly, I suppose, although I really don't feel that way; maybe because this has been the case for so many years now that it is no longer, and has not been for a very long time, an "emotional" issue for me - it would be kind of like having "feelings" about the fact that the sky is blue) I no longer use "tools" like "grep" and the like (unless I'm essentially "forced" to, which hasn't happened for many years) because I have used too many pattern-matching programs of one kind or another over the years (almost 40 years at this point); and in most cases the program I used was the only program I could use at that particular point in time for whatever reason such as operating system/availability/whatever so that I had to learn the syntax of its "regular expressions"; and with my developing bad memory I found remembering the particular syntax of the "patterns" of this particular program vs. the syntax of the "patterns" of all of its "alternatives" (and the fact that the individual syntax of the patterns for the various programs are typically very similar but not identical actually makes things far worse for me because trying to remember the small syntax differences between this particular program vs. that particular program became simply more than I could handle). For me, the simple "*" and "?" "wildcards" like in TCC and even plain old DOS are sufficient for my needs probably upwards of 95% of the time; and when they are not I could easily "come up with" an alternative, fairly simple like my suggested "solution" above is, way to do it that I can pretty much immediately fully understand. Yes, I can "read" the pattern in your "grep" (barely!), but trying to compose it would simply take too much time and effort for me and looking at a "help document" of some kind whereas, for me (and probably no one else) my solution was simple and straightforward and required almost no thought whatsoever - or, to say it another way, your "solution" is, without any doubt whatsoever, better than mine is in a "general" sense; but I will still continue to do things my way because they are, for me, simple and straightforward and require almost no thought. However I (will at least try to remember to :)) not "answer" any more questions like that on this bulletin board!
- Dan
I truly am laughing as I type this.:) Your answer is so correct and so obvious. However I will note that (somewhat sadly, I suppose, although I really don't feel that way; maybe because this has been the case for so many years now that it is no longer, and has not been for a very long time, an "emotional" issue for me - it would be kind of like having "feelings" about the fact that the sky is blue) I no longer use "tools" like "grep" and the like (unless I'm essentially "forced" to, which hasn't happened for many years) because I have used too many pattern-matching programs of one kind or another over the years (almost 40 years at this point); and in most cases the program I used was the only program I could use at that particular point in time for whatever reason such as operating system/availability/whatever so that I had to learn the syntax of its "regular expressions"; and with my developing bad memory I found remembering the particular syntax of the "patterns" of this particular program vs. the syntax of the "patterns" of all of its "alternatives" (and the fact that the individual syntax of the patterns for the various programs are typically very similar but not identical actually makes things far worse for me because trying to remember the small syntax differences between this particular program vs. that particular program became simply more than I could handle). For me, the simple "*" and "?" "wildcards" like in TCC and even plain old DOS are sufficient for my needs probably upwards of 95% of the time; and when they are not I could easily "come up with" an alternative, fairly simple like my suggested "solution" above is, way to do it that I can pretty much immediately fully understand. Yes, I can "read" the pattern in your "grep" (barely!), but trying to compose it would simply take too much time and effort for me and looking at a "help document" of some kind whereas, for me (and probably no one else) my solution was simple and straightforward and required almost no thought whatsoever - or, to say it another way, your "solution" is, without any doubt whatsoever, better than mine is in a "general" sense; but I will still continue to do things my way because they are, for me, simple and straightforward and require almost no thought. However I (will at least try to remember to :)) not "answer" any more questions like that on this bulletin board!
- Dan
It is documented that when SET is used to display currently defined environment variables, the only wildcard available is * - but why? IMHO the operation of the SET command in this mode ought to match how the ALIAS and FUNCTION commands perform the analogous tasks: the ? wildcard is interpreted as a match for a single character. "FUNCTION ??" displays all UDFs with 2-character names; "ALIAS ??" displays all aliases with 2-character names. There may exist a Windows API call to perform the current operation, but obviously it is not available for ALIAS or FUNCTION definition display. Whatever code is used by ALIAS and FUNCTION could be modified to enhance SET's display, and incidentally make it also function with registry variables (/D, /S, /U and /V).
SET with unsupported wildcards causes TCC 13.0.38 to close with neither GPF nor any other notification. Try "SET [AB]*" - TCC will disappear. V12 and V11 behave the same. V10 generates a GPF and triggers the "report to Microsoft" pop-up. V9, V8, V7 and V6 display "TCC: Not in environment "[ab]*"
and proceed to the prompt.
SET with unsupported wildcards causes TCC 13.0.38 to close with neither GPF nor any other notification. Try "SET [AB]*" - TCC will disappear. V12 and V11 behave the same. V10 generates a GPF and triggers the "report to Microsoft" pop-up. V9, V8, V7 and V6 display "TCC: Not in environment "[ab]*"
and proceed to the prompt.
Because some people are crazy enough to use question marks, brackets, etc. in variable names?
Well, I was hoping to do it with FFIND. But it appears that FFIND always quits at the first match. (Is there any way to override that?)
Yeah! Why does it do that? Stopping after the first match is supposed to be an option (/F).
Code:
e:\logs\mercury> set | ffind /e"^..=" /k /m
AE=3This (below) works, avoiding externals. But I really wanted to do it with just SET.
Code:
e:\logs\mercury> set | do line in @CON ( if %@regex["^..=",%line] == 1 echo %line )
AE=3
AF=2
AL=3
(snip)Hah!
Regexps usually look like someone spilled a box of toothpicks. That one looks more like a Japanese "Hello Kitty" smiley.
Code:
set | ffind /e"^.[^=]=" /v /k /mIt also stops after the first line when not in a pipe.
Code:
e:\logs\mercury> ffind /e"." /m /k MERCURYS.LOG
T 20100601 033308 4bb58e47 Connection from 74.71.55.217
Code:
(system) C:\...\TCCLE >set aa=1234
(system) C:\...\TCCLE >set bb=dfjsdfgjsdfg
(system) C:\...\TCCLE >set cc=****************
(system) C:\...\TCCLE >set | for %x in (@con:) (set i=%@index["%x",=] %+ if %i eq 3 echo %@word["=",0,%x])
aa
bb
cc
OSFrank,
Your solution is certainly very good and very clever (I've never had a known reason to use any of the "@Word..: functions in the past, so I know very little about them other than the fact that they exist) and hopefully Vince, who started this thread, can take advantage of it since it is clearly one of the best solutions suggested so far. However, since my "solution" works fine and since I can both remember it and easily understand it there is no incentive for me to change anything. But thank you (at least for Vince! :))!
- Dan
Your solution is certainly very good and very clever (I've never had a known reason to use any of the "@Word..: functions in the past, so I know very little about them other than the fact that they exist) and hopefully Vince, who started this thread, can take advantage of it since it is clearly one of the best solutions suggested so far. However, since my "solution" works fine and since I can both remember it and easily understand it there is no incentive for me to change anything. But thank you (at least for Vince! :))!
- Dan
Hi Dan,
@word is one of my favorite functions.
I often have to deal with logfiles or other machine-generated output.
And with @word you can comfortably test the contents whether it contains the desired keyword (at a certain position) you are looking for and pick it up for further usage.
regards
Frank
@word is one of my favorite functions.
I often have to deal with logfiles or other machine-generated output.
And with @word you can comfortably test the contents whether it contains the desired keyword (at a certain position) you are looking for and pick it up for further usage.
regards
Frank