Reply to post: Re: It's not difficult you know

Re: It's not difficult you know

Couldn't have it been done with an extension of CMD and more external commands?

No. The cmd language is fundamentally broken. Fixing it would break existing cmd scripts.

or at least add what doesn't fit as an evolution of VBScript?

Well, that's more plausible, particularly since WSH (Windows Scripting Host, which actually runs VBScript scripts) supports multiple languages; at least JScript is implemented, so there's an alternative to VBScript (which I find horrible) in the same engine. And WSH has both CLI and GUI modes. Combine WSH with WMI and it's a plausible admin interface.

Of course, it's still around, as far as I know. Has it been removed from more recent versions of Windows? I know Powershell is the only scripting interface for some tasks (eg some Exchange stuff), but lots of things have stand-alone CLI tools, WMI interfaces, or WSH interfaces.

why the heck did they have to reinvent the wheel like this?

Because every other computer scientist wants to create a programming language. And Powershell's OO model does have some things to recommend it. It's highly parallel with a lot of conventions, so different commands - including the extensions written by third parties - generally support similar options and behaviors. I don't find it viscerally attractive, particularly; I use Cygwin bash as my Windows shell. But I've worked with Powershell and my team has developed some substantial extensions for it, and for actually writing scripts (as opposed to ad hoc twiddling) it has some real strengths.

I mean, I can administer Unix boxes using the same shell I was using 25+ years ago.

Shrug. I can administer Windows boxes using the same shell I was using 25 years ago. Well, it'd be Cygwin bash running in Bourne Shell emulation mode, but close enough.

I never had to re-learn the alphabet like I feel I have to do now with this Powershell crap

Sorry, but that's a feeble objection. Microsoft acknowledged that their existing CLI administrative tools were insufficient. They looked at the problem and decided to fix it properly, with a tool that was robust, consistent, and could handle future requirements cleanly. "I don't wanna learn something new" may be a reason to ignore the result, but it isn't a valid critique of it.

When I started doing AS/400 development in the late '80s I had to learn a system that was nothing like any I had used before - not at all like UNIX or Windows or MS-DOS or VMS or ISPF/TSO on MVS or any of the others. It wasn't much like anything else in the world, except the never-released Future Systems and some aspects of System/3x (which I'd never used). But I sucked it up and learned how to work with it. When a new system comes along you can adapt or you can refuse to do so, but blaming it for being new is childish.