Olin Lathrop wrote:

> Gerhard Fiedler wrote:
>> FWIW, the fact that you're (still) talking about .bat files (which
>> mostly continue to exist for backwards compatibility with -- here it
>> comes -- MS-DOS :) might suggest that more than a decade in Windows
>> shell development went by you without leaving a trace. cmd.exe is
>> not bash, but IME it can do much more than most of its bashers seem
>> to know.
> 
> I guess I'm missing something.  

Probably... :)

> Yes CMD.EXE is a lot more capable than COMMAND.COM, the DOS command
> line processor.  However, files for CMD are still named .BAT as far
> as I know.  Is there some different suffix that turns on more
> extended features by default? 

No, but see my other message for details.

> I agree CMD has a lot more hidden features than most people seem to be
> aware of.  However, I've used several different command shells and
> consider CMD to be the worst of the bunch.  I think the syntax for
> doing some things is unnecessarily squirrely.  

As compared to what? One of the most common "high functionality" shells
is bash, but its syntax is quite, ahem, "squirrely", too -- IMO, of
course :)

I'd like to know a shell that's common and ideally free (so that scripts
can be shared), that is multi-platform (the common platforms) and that
has a consistent and intuitive syntax. Any ideas?


> Then there is the problem of very poorly handled "delayed environment
> variable expansion".  This can be enabled on the CMD command line,
> but as far as I know a script can't enable it inside.  That means you
> can't rely on it being on or off in a script a customer might run
> because you don't control the CMD invocation.  You could have your
> script run a second CMD invocation with the switch explicitly set,
> but that makes the shell scripts that rely on that very messy. 

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.)

This is exactly what I'm talking about... even people who normally know
their stuff seem to approach cmd.exe with a mindset of "it can't do it
anyway (because command.com twenty years ago couldn't do it)" and won't
even look whether it can do it.

> The hard limit of 9 command line arguments to shell scripts is
> another limitation. 

This is another example of what I'm talking about. There's no limit of 9
command line arguments. (Check out the command shift.)

> In the end you can get done what you need with CMD.  If you're doing
> anything advanced though, it's usually not as nice and simple as with
> other command shells. 

If you (with what you wrote) can get done what you need, imagine someone
who actually knows cmd.exe :)

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