Hacker News new | ask | show | jobs
by ygra 3456 days ago
But as long as you only execute programs a script for cmd, bash, PowerShell and a number of other shells looks pretty much the same. In PowerShell executing a program is simply to state the program name (barring spaces in the path for now). You don't have to do something like execute_program(name, args, input_redirection, output_redirection, ...). Well, you can, if you're so inclined, but it's usually unnecessary. Any shell is "just a REPL for a scripting language". Interactive use is one of the tenets of a shell, otherwise it's more a batch processing system, I guess. And just like in other shells the language is one geared towards running commands (cmdlets or external), managing their execution and processing their output. That it works better for general programming than many other shell languages (in my eyes) is a nice bonus.

Heck, running programs is even easier than in most other shells since there's a specific token that stops argument parsing completely which means you don't have to care about quoting at all (an ever-present nightmare at times).

1 comments

The difference is that windows/PowerShell don't provide the programs that make a she'll useful.
Wow, then I've done a lot of apparently-useless PowerShell work.

I beg to differ, by the way. Different is not the same as »not useful«. It's not a traditional Unix shell and doesn't pretend or want to be. That doesn't make it useless, just different.

It's not a traditional Unix shell and doesn't pretend or want to be.

Except in the sense that it provides aliases for most popular Unix shell commands. They even made their aliases incompatible with other Unices, like every other traditional Unix shell.

I agree that powershell is far from useless, but it does feel like there are a lot of cmdlets missing out of the box. It's real easy to end up in Get-WmiObject land for everyday admin tasks.
But WMI is really, really huge. I can understand that there is a bit resistance to providing cmdlet wrappers around every single WMI class, although I think on Windows Server there are a lot more things exposed by default (and I think even more in modules that are not loaded by default).

Also, since PowerShell can work with WMI objects natively it's already close to what a cmdlet can provide.