By registering with us, you'll be able to discuss, share and exchange private messages with other members of our community.
SignUp Now!v:\> do var in /L %_varnames (echo %var)
ALLUSERSPROFILE
APPDATA
CommonProgramFiles
COMPUTERNAME
ComSpec
DebugVariableExclude
**SNIP**
How about:
for var in ( path appdata path ) echo %%var = %var
or the DO equilivent....
----- Original Message -----
From: vefatica
To: [email protected]
Sent: Friday, August 20, 2010 10:43 PM
Subject: [Suggestions-t-2268] Loop on environment variable names?
Is there a way to loop (DO/FOR) on environment variable names? ... say "DO varname in @ENV". The only mechanisms I can think of are cumbersome. I suppose I could write a plugin to provide a word list of variable names, but it would be better built-it to DO.
>I meant loop on **all** variable names. Like this (with the help of
>an experimental plugin _VARNAMES):
IN=135
RU=56
US=50
UA=45
CN=38
BR=35
TW=29
KR=29
VN=23
GB=20
ES=20
CA=19
RO=18
DE=17
NL=15
CO=14
GR=13
KZ=12
EG=11
CL=10
TH=9
PL=9
ID=9
MA=8
SNIP - complete list available
v:\> do var in /P VARNAMES "^^[A-Z]{2}$" (set /a total+=%[%var])
v:\> echo %total
768
DO var in /E "^^[A-Z]{2}$" (set /a total+=%[%var])
> Is there a way to loop (DO/FOR) on environment variable names? ...
> say "DO varname in @ENV". The only mechanisms I can think of are
> cumbersome. I suppose I could write a plugin to provide a word list
> of variable names, but it would be better built-it to DO.
>
>
>
>
> On Mon, 23 Aug 2010 19:12:50 -0400, K_Meinhard
> <> wrote:
>
> |---Quote---
> |>I meant loop on **all** variable names. *Like this (with the help of
> |>an experimental plugin _VARNAMES):
> |---End Quote---
> |Wouldn't this do what you want:
> |
> |:: LOOP.BTM
> | *@echo off
> | *set > %temp\SET.DAT
> | *do l in @%temp\SET.DAT
> | * * *set var=%@word["=",0,%l]
> | * * *set val=%@word["=",1,%l]
> | * * *echo %var = %val
> | *enddo
> | *del /q %temp\SET.DAT
> | *quit
>
> Yes it does. *But it's rather cumbersome.
v:\> type dodo.btm & dodo.btm
timer /q
do i=1 to 500
do line in /P set /x
echo %line > nul
enddo
enddo
timer
timer /q
do i=1 to 500
set /x > vars.txt
do line in @vars.txt
echo %line > nul
enddo
del /q vars.txt
enddo
timer
Timer 1 off: 21:33:39 Elapsed: 0:00:16.16
Timer 1 off: 21:33:47 Elapsed: 0:00:07.70
Is there a way to loop (DO/FOR) on environment variable names? ... say "DO varname in @ENV". The only mechanisms I can think of are cumbersome. I suppose I could write a plugin to provide a word list of variable names, but it would be better built-it to DO.
setarray x[1024]
set y=%@execarray[x,set]
for /l %f in (0,1,%@dec[%@arrayinfo[x,1]]) do if %@len[%x[%f]] GT 0 echo %@word["=",0,%x[%f]] = %[%@word["=",0,%x[%f]]]
> On Mon, 23 Aug 2010 20:42:42 -0400, DMcCunney
> <> wrote:
>
> |Out of curiosity, how often do you need to do it?
>
> Recently, once. *But if the functionality had been there for the last
> 20 years or so I probably would have used it a few times
> |I recall seeing requests back in the old 4DOS days to build in
> |functionality that could either be provided by third-party
> |applications called from 4DOS, or implemented through 4DOS BTM files.
> |A lot of them struck me as "This is something else's job. *Use the
> |something else." cases, and so does this.
>
> TCC is chock-full of functionality which is provided by third party
> apps, or which can be accomplished with a script (often with no loss
> of speed). *A good example is DO's processing each line of the output
> of a command. *The good old fashioned way (a temp file) is much
> faster:
> |I spend a lot of time playing in the Unix sandbox, and in that
> |environment, my reflex is to create a shell script akin to the above,
> |and not request that the bash maintainers make it a built-in.
> |Built-ins are called for where there is a significant performance
> |improvement, but that assumes it's something I'll be doing a *lot*.
> |(And is why, for example, the Korn shell added things like integer
> |arithmetic as a built-in, rather than calling eval as an external:
> |doing math in a script *did* happen a lot, like keeping count in a
> |loop. *The same goes for making echo a built-in, aliased to the
> |internal print command, instead of calling /bin/echo every time you
> |wanted to write something to the screen. *The performance increase
> |made it feasible to write entire applications in the shell.)
>
> You're pretty much stuck with that in the UNIX world. *How often do
> UNIX shells get new features? *I was a tcsh junkie 15 (or so) years
> ago. *I'll bet it hasn't changed much.
> I think it's Rex's goal to (within reason) give the users what they
> want.
> And speed ... I'm obsessed with it a little more than most.
setarray varnames[512]
set i=0
for /f "delims==" %var in ('set /x') (set varnames[%i]=%var & set /a
i+=1)
DO varname in @ENV:
DO varname in /E [regex]
> On Mon, 23 Aug 2010 23:43:21 -0400, DMcCunney
> <> wrote:
>
> |When you start wanting to add things that are normally the
> |province of an external program, instead of calling that external
> |program from a script, you are arguably missing the point of what the
> |shell is supposed to be.
>
> So what do you think of TCC? *It's already far beyond your definition
> of a shell.
I'd say it's not "totally true".These days, pretty much everyone is moving to bash. Bash tries to be one-size-fits-all, and is what happens when you can't decide whether you want a shell like the Bourne shell or a shell like the C shell, and you compromise and create one that combines most features of both, plus a few wrinkles of its own.
> ---Quote (Originally by DMcCunney)---
> These days, pretty much everyone is moving to bash. *Bash tries to be one-size-fits-all,
> and is what happens when you can't decide whether you want a shell like the Bourne
> shell or a shell like the C shell, and you compromise and create one that combines most
> features of both, plus a few wrinkles of its own.
> ---End Quote---
> I'd say it's not "totally true".
> I observe quite opposite trend in attempt to make everything strictly sh-compatible
> (and it's really not hard). Even bash itself leaning toward closer resemblance of POSIX sh.
> You maintan built-in perfomance improvements of, say, bash, but you get as much
> compatibility as possible out of the box.
> And I can't name it as bad thing.
_____> Rex Conn
> JP Software
I'm still toying with plugin solutions. At the moment I have a "VARNAMES regex" command.
And now I'm imagining an enhancement to DO like this, where /ECode:v:\> do var in /P VARNAMES "^^[A-Z]{2}$" (set /a total+=%[%var]) v:\> echo %total 768
indicates looping on environment variable names matching the regex.
Code:DO var in /E "^^[A-Z]{2}$" (set /a total+=%[%var])
@setlocal
@echo off
if not plugin iso8601 plugin /l c:\utils\iso8601
if isplugin qcal qcal %1 %2 %3 %4 %5
if plugin iso8601 plugin /u iso8601
endlocal
@@ctrl-q=qcal /i /3
Why not just go the plugin route? For example, I use Charles Dye's ISO8601 plugin everyday, mainly for the QCAL command.
Should TCC have a builtin QCAL command?
v:\> for %v in (a "b c" d) echo %v
a
"b c"
d
v:\> do v in /L a "b c" d (echo %v)
a
"b
c"
d
> | But the Unix philosophy has always been one tool for one job, and
> | using scripts to tie tools together when you needed to do more than
> | one job as part of your process.
>
> * *Sorry to reply this late (I had read-only internet access), but therein
> lies the problem: each tool has its own, unique command line, with different
> tools having completely different methods of specifying the same option.
> There is not even any consistency in how to specify that most common file
> processing case, a single input file and a single output file. Some require
> redirection, some require "source destination" order, some require
> "destination source" order.
> Cf. 4DOS/4NT/TCC - there is nearly 100%
> consistency between commands on how to specify each available option. Once
> you learned the basic syntax, you have it for all commands.
> And another
> point - because it is a single program, its documentation include all
> "tools". In the POSIX world, when you need to do a specific task, its up to
> your memory whether or not you can find the actually available tool. If you
> don't know its name, you may need to spend many hours browsing "man-pages"
> to find it.
_____> Steve
I suppose that's what I'll do since there hasn't been much interest
expressed.
Getting the varnames (even matching a regex) is almost trivial but
thete are two things I can't overcome with a plugin.
"DO var IN /P command" is far slower than "DO var IN /L list". And if
a varname contained a space (rare but possible), DO /L would not
process a list (say from _VARNAMES or @VARNAMES[regex]) correctly.
Nearly everywhere else in TCC a quoted string is treated as a single
token; but not for DO /L.
Code:v:\> for %v in (a "b c" d) echo %v a "b c" d v:\> do v in /L a "b c" d (echo %v) a "b c" d
do var in /t"=" /l a=b c=d ( echo %var )
VARNAME WITH SPACE=ALLUSERSPROFILE=APPDATA=CLIENTNAME
v:\> for /T"=" %v in (VARNAME WITH
SPACE=ALLUSERSPROFILE=APPDATA=CLIENTNAME) echo %v
VARNAME WITH SPACE
ALLUSERSPROFILE
APPDATA
CLIENTNAME
v:\> do v in /T"=" /L VARNAME WITH
SPACE=ALLUSERSPROFILE=APPDATA=CLIENTNAME (echo %v)
VARNAME WITH SPACE
ALLUSERSPROFILE
APPDATA
CLIENTNAME
(No parentheses around the string set in this syntax. No, I don't know why.)
> | good try at taking over the world. *Back then, you could probably
> | pick up the phone or walk down the hall and talk to the guy who wrote a
> | particular utility if you weren't sure what was going on.
>
> Yes, about 1986 I was working as a contractor at Bell Lab, and just picked
> up the phone to ask a question about ksh - from none other than Dr. Korn!
> But even then Bell Lab people forced to use Unix for such things as
> accounting (and not software development) hated its absolutely and
> completely user unfriendly interface.
> | ---Quote---
> || Cf. 4DOS/4NT/TCC - there is nearly 100% consistency between
> || commands on how to specify each available option. Once you learned
> || the basic syntax, you have it for all commands.
> | ---End Quote---
> | Yep. *It's a strength. *The weakness is that it's not portable: if you are
> | using 4DOS/4NT/TCC you are running a flavor of MS-DOS/Windows.
> | If you are running something that isn't an Intel architecture PC or an
> | OS that wasn't made by Microsoft, You must use a different tool set.
> | The reverse is less true - ports of the *nix tools exist for Windows in
> | things like Cygwin or Microsoft Services For Unix.
>
> That's because it is not commercially viable to port it. Were it otherwise,
> the oft requested 4NIX would have long been available. However, I have used
> 4DOS long ago on Solaris' which had a DOS emulator.
> | ---Quote---
> | And another
> || point - because it is a single program, its documentation include
> || all "tools". In the POSIX world, when you need to do a specific
> || task, its up to your memory whether or not you can find the
> || actually available tool. If you don't know its name, you may need
> || to spend many hours browsing "man-pages" to find it.
> | ---End Quote---
> | <shrug> *If you're in the POSIX world, you learn. *I suspect the
> | 80/20 rule applies there, too - 80% of the users use 20% of the commands,
> | and become familiar with the syntax for the commands they use. *If
> | they find themselves needing to do something not covered by the stuff
> | they know, they need to find out what does it and how it's invoked
> | (and may need to install it if it's not part of the default install
> | on their system.)
>
> The issue in the POSIX world is "how do you learn" - what's missing is the
> equivalent of the sections of TCC documentation titled "... by category".
> All programming language manuals published by their vendors I've ever seen
> (and there are many) are organized by category. Only the POSIX world demands
> rote learning.
_____> Steve
If that's what you want, then I suggest you use the QCAL plugin instead. It only provides the QCAL command and a minimal subset of functions (just enough to parse Holidays.ini.)
> ---Quote---
> >I meant loop on **all** variable names. Like this (with the help of
> >an experimental plugin _VARNAMES):
> ---End Quote---
> Wouldn't this do what you want:
>
> :: LOOP.BTM
> @echo off
> set > %temp\SET.DAT
> do l in @%temp\SET.DAT
> set var=%@word["=",0,%l]
> set val=%@word["=",1,%l]
> echo %var = %val
> enddo
> del /q %temp\SET.DAT
> quit
>
> Best Regards,
>
> * Klaus Meinhard *
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
v:\> do v in /T"=" /L %@varnames[] ( echo %v )
ALLUSERSPROFILE
APPDATA
CLIENTNAME
CommonProgramFiles
(snip)