Olin Lathrop wrote:

>> You can't be serious... If that ever was an issue for you, the first
>> page of Google hits when searching for "cmd.exe delayed environment
>> variable extension" is full of information about how to solve your
>> problem. (Check out the variable ENABLEDELAYEDEXPANSION.)
> 
> I didn't know about that.  Now that I know where to look it up, I
> found this described in the SETLOCAL command. 
> 
> That brings up another gripe with CMD: The documentation sucks.  I
> like to RTFM before using something.  

I do, too, and I agree. Most Microsoft documentation sucks; it tends to
explain the obvious and not the purpose, the background, the stuff one
needs a (good) documentation to know.

But for quite a while now, I've added web searches to my tool box. When
I can't find something quickly in the "official" documentation, I search
for it with my favorite search engine. Usually it doesn't take long to
find the answer (if there is one). 

This question is an example. I didn't know about this, it never came up
for me, but I knew that there is more to cmd.exe than the documentation
makes it look like. Everybody who has worked a bit with it probably has
made this experience. So I put exactly your question in Google, and the
first page was full of hits that are right on target (none by Microsoft,
though, but I don't care so much where I get my info from :)

> It's no wonder most people don't know all CMD can do, even those that
> have tried.  Knowing the range of things that are possible is exactly
> why I like to RTFM before starting. 

All granted, but what I still find surprising is that it seems that
things that can be answered with ten seconds of web search are still not
known. It must have taken you longer to write the paragraph about this
not being possible than it would have taken you to find out that there
is a solution for your problem. This is not exactly typical for you, and
not for many of the others that I've encountered with the same issue.


> No, it's more "it can't do it because I saw no mention of it after a
> reasonable search".  

We probably disagree on what constitutes a "reasonable search". Typing
your question into Google and checking out the promising among the first
ten hits constitutes for me part of a "reasonable search". 

> For example, most shells let you get the output of a program into a
> environment variable.  When I first started using CMD I found it very
> frustrating that it couldn't do that.  I looked in all the obvious
> places (you have to specifically look since there is no overview to
> read), like the SET command, looked for "assignment", and the like. 
> A few years later I accidentally noticed this can be done with the
> FOR command when I was looking up how to do something unrelated.

Again, granted about the bad Microsoft documentation. However, also
again, the solution is described in the second Google hit for "cmd.exe
output to environment variable". 

Microsoft documentation is bad, but this doesn't mean that the stuff
isn't around.

> Try just finding a list of the commands built into CMD.  The help
> gives you a list of commands available in Windows, but I don't
> remember any list of just the built in commands so that you can get a
> introduction and find things like that.

Hm... Google for "cmd.exe built-in commands", follow the second link
(this time this is actually a Microsoft link) to the Microsoft page for
the "Cmd" command and scroll to the bottom. 

I agree that the documentation could be better, but I've found that so
many things people seem to assume that cmd.exe can't do are /really/
easy to find. I mean with this that solutions are available among the
first ten hits of a Google search with intuitive search terms.


>> This is another example of what I'm talking about. There's no limit
>> of 9 command line arguments. (Check out the command shift.)
> 
> Yes you can do that, but that's more a workaround for the limit.  In
> better shells you don't have to do that.

There simply is no limit of 9 for the number of command line arguments;
just get this out of your head. The limit is for the number of command
line arguments that you can address directly by position. 

FWIW, writing a script that uses more than 9 arguments by position is,
ahem, bad design anyway. With that many arguments, they should be
standard arguments whose meaning is not dependent on their position.
Once you don't use positional arguments, addressing them by their
position becomes irrelevant; you iterate through them (for that, shift
is perfectly usable), parse them, store the relevant results in
variables, and forget about them. No need to address arguments by
position.


The other issue is of course that /if/ you write shell scripts on
Windows for a reasonable amount of time as part of your professional
activities and value your time, you should have started to use 4DOS/4NT
a loooong time ago. Not free, but well worth its money. You've probably
lost more money trying to find how to do stuff with cmd.exe than you
would have spent on 4NT. There is a free version of TCC (the successor
to 4NT) available from JP. 

I've never felt the need to complain about bad shells on Windows. For
one, I've been using 4DOS/4NT/TCC forever. Awkward like pretty much all
common shells, but quite a bit more powerful than command.com/cmd.exe,
and better documented. For anybody who's doing professional shell work
on Windows and who's complaining about cmd.exe, it usually takes more
time to complain than just to get something better. (This includes bash,
for example, and I can't get rid of the impression that most of the
cmd.exe complainer would complain just as loudly about bash -- after
all, there must be a reason why they are not using it :) For another,
most things people complain about Windows shells has a simple to find
solution, and can be translated into "was too lazy to search for it".
And still for another, if you really need advanced functionality, you're
most likely already outside of interactive shell use and into writing
shell programs, and JavaScript, VBScript, Perl, Python et al are just as
suited -- and quite often much better suited. Just because Unix guys are
used, mostly for historical reasons, to write programs in their shells
doesn't mean that this is necessarily a good thing :)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist