Agree about PowerShell. It's not just that the scripting language sucks, which as you show it does. But nearly everything about PowerShell is bad. For example:
1) It takes a good 4 or 5 seconds to boot PowerShell. This is unacceptable, a terminal emulator should boot near instantaneously.
2) Cmdlets are really freaking hard to write or use. It's hard for users to enable them, it's hard for users to install them, and it's especially hard for programmers to create them. Unix shells are much easier for all parties involved.
1: Just a note, PS is a shell, not a terminal emulator. And yes, Windows could really use a decent terminal program - the standard console is terrible.
2: The hard-to-enable is a result of Microsoft's pro-security standing. They got a bad rep for allowing scripts to run freely in the past, so they tried to lock it down.
As far as developing and using them, I dunno, it seems vastly better than bash. Sane quoting that helps avoid injection mistakes. Auto-complete built-in throughout the system. Actual types, instead of just passing strings everywhere. And they ship a nice little editor/debugger with it, if you'd like that kind of thing.
No, cmdlets are hard to develop. You have to follow a hard-to-understand API that doesn't ship with the operating system. With bash it is stdin and stdout... that's all you really need to know to write any shell script. With PowerShell you have to write a very particular type of script that compiles to .NET (and again DOES NOT SHIP WITH THE OS); your language choices are limited to about 3. Interoperability is important to something as fundamental as shell scripting and PowerShell is not interoperable.
I lost you on your "Does not ship with the OS" point. What are you referring to?
PowerShell has shipped with the OS since WS 2008 and Vista. We have ALSO made it available to prior versions of the OSes (e.g. down to XP.
I also missed your point about interoperability of shell scripting and PowerShell.
PowerShell can launch any process, pipe data to it and read/parse the data that it generates.
PowerShell can be launched by any process and read/write text.
So when you say "interoperate" that is what I'm thinking of so I think they interoperate well. Are you referring to something else or are you experiencing a problem?
Thanks!
Jeffrey Snover [MSFT]
Distinguished Engineer and Lead Architect for Windows Server and System Center
> I lost you on your "Does not ship with the OS" point. What are you referring to?
The SDK for developing cmdlets. This would be equivalent if on unix you needed an extra download to write to stdout/stderr.
> So when you say "interoperate" that is what I'm thinking of so I think they interoperate well. Are you referring to something else or are you experiencing a problem?
Cmdlets can only be developed by languages created by Microsoft. You cannot write a cmdlet in Python, Perl, or even C.
The app tends to boot fast but you have to wait for .NET to warm up before you can use it. I'm talking about usability time. It's also much faster after you've initially opened the app.
1) What version are you running?
We had a problem with earlier versions that didn't NGEN and had startup delays.
With V2 we made it so you can write cmdlets in PowerShell itself which is pretty simple.
With V3 we added auto-loading of Modules which allowed Xcopy deployments and simplified discovery.
We just released V4 so you might want to give a more recent version a try.
2) What don't you like about the language? Is it just personal preference or are there things you can't do or are too hard to do?
Thanks!
Jeffrey Snover [MSFT]
Distinguished Engineer and Lead Architect for Windows Server and System Center
1) It takes a good 4 or 5 seconds to boot PowerShell. This is unacceptable, a terminal emulator should boot near instantaneously.
2) Cmdlets are really freaking hard to write or use. It's hard for users to enable them, it's hard for users to install them, and it's especially hard for programmers to create them. Unix shells are much easier for all parties involved.