3 ms·

You don't even need the specification to implement cmdlets. Heck, you could extend PowerShell exclusively in PowerShell code (though performance makes that some

by ygra 12y ago

You don't even need the specification to implement cmdlets. Heck, you could extend PowerShell exclusively in PowerShell code (though performance makes that somewhat undesirable most of the time).

apalmer 12y ago
The downsides to powershell are mostly around the fact that along with some good innovation they also threw out a lot of other standard conventions. Which makes it tedious to integrate powershell with other command line tools. Also another thing I have a problem with is the startup time, for a lot of quick hacks, I can start up, execute and close down the terminal (cygwin lets say) in the time i am still waiting for powershell to initialize. Not huge problem but for me it holds me back from using powershell somewhat.
- ygra 12y ago
  As for command-line tools, the things that come to mind right now (that can be tedious) are 1. Result of a command-line tool is its output, not its exit code, so you have to use $LastExitCode when treating command-line invocations as boolean values 2. Stream behaviour other than stdout gets weird when redirecting one stream into another (e.g. 2>&1 causes every line that's output on stderr to be thrown as an exception. 3. Encodings are a mess, sadly. They mangle Unicode output from external programs. This was a compatibility decision, but it's unfortunate, especially because the appropriate .NET APIs are a bit clunky to use. 1 is just different from bash, 2 and 3 can be dealbreakers depending on what you do, and the workaround is the same, but annoying, admittedly. The one-second startup time has been awful, I know. Although for me at least since Windows 8 it has been instantaneous, making this a non-issue. (Pash is worse at about two seconds currently, though.) But from the time when Powershell was slow to start I still have a habit of just running cmd for things that can be done in cmd.

by ygra 12y ago

You don't even need the specification to implement cmdlets. Heck, you could extend PowerShell exclusively in PowerShell code (though performance makes that somewhat undesirable most of the time).

apalmer 12y ago

The downsides to powershell are mostly around the fact that along with some good innovation they also threw out a lot of other standard conventions. Which makes it tedious to integrate powershell with other command line tools. Also another thing I have a problem with is the startup time, for a lot of quick hacks, I can start up, execute and close down the terminal (cygwin lets say) in the time i am still waiting for powershell to initialize. Not huge problem but for me it holds me back from using powershell somewhat.

ygra 12y ago
As for command-line tools, the things that come to mind right now (that can be tedious) are 1. Result of a command-line tool is its output, not its exit code, so you have to use $LastExitCode when treating command-line invocations as boolean values 2. Stream behaviour other than stdout gets weird when redirecting one stream into another (e.g. 2>&1 causes every line that's output on stderr to be thrown as an exception. 3. Encodings are a mess, sadly. They mangle Unicode output from external programs. This was a compatibility decision, but it's unfortunate, especially because the appropriate .NET APIs are a bit clunky to use. 1 is just different from bash, 2 and 3 can be dealbreakers depending on what you do, and the workaround is the same, but annoying, admittedly. The one-second startup time has been awful, I know. Although for me at least since Windows 8 it has been instantaneous, making this a non-issue. (Pash is worse at about two seconds currently, though.) But from the time when Powershell was slow to start I still have a habit of just running cmd for things that can be done in cmd.