6 ms·

Powershell should have been set as default years ago, particularly on core. It escapes me how windows admin community still largely ignores Powershell while cl

Powershell should have been set as default years ago, particularly on core. It escapes me how windows admin community still largely ignores Powershell while clicking next in the loop. Until MS makes Windows Powershell first, adoption will change very slowly as we witnessed so far. Nano server will hopefully bring it faster. Its a terrible injustice as posh is best shell in the existence IMO. What I really want to see in future is exporting entire control pannel config as posh script. This is the perfect time to digg into it given that control panel is being transformed into 'settings'.

josephcooney 10y ago
The horrible syntax of Powershell isn't something I can look past.
- alkonaut 10y ago
  I think it's fairly neat (I mean - for shell scripting not for interactive use). The problem with shells is that they want to do both. The alias system in PS tries to make it possible to use a more bash-like syntax in interactive and the verbose syntax in scripts, which is a good idea, but it's hard to get right.
  - ygra 10y ago
    As someone who golfs in PowerShell and very frequently uses it interactively too, I think the complaints about lack of terseness are quite overblown. Aliases, parameter binding by position or pipeline, the ability to shorten parameter names as long as they remain unambiguous, parameter aliases – all features that are most important for interactive use. Apart from a few nagging things where parameter prefixes clash (gci -f matches Force and Filter) I think it's quite good. Besides, I gladly pay that little price for much improved readability, discoverability and memorability. No more pondering whether the -Recurse flag is -r or -R in this particular command, for example.
    - noinsight 10y ago
      Also, since PowerShell is able to tab-complete cmdlets, parameters, parameter values (when they're enumerable) and even object properties, you hardly have to type much most of the time. The only problem with the tab-completing is that since everything has a standard verb prefix, you always have to type the beginning of the cmdlet name.
pshposh 10y ago
PowerShell is almost like using the python interactive interpreter as your command line but better. I was convinced how cool it was when I could import a C# .dll and load the types into PowerShell. You can even just write C# 'inline' and it compiles it on the fly. It baffles me as well how many Windows people I work with ignore it almost.
- NoGravitas 10y ago
  This is really the best analogy to explain PowerShell to Unix people. PowerShell's sweet spot is really not interactive use, but sysadmin-type scripting. It's very much like using Python for sysadmin tasks.
  - Too 10y ago
    So essentially it's a programming language? For "scripting", why would I use it over just plain c#?
    - paulmooreparks 10y ago
      Because C# is designed around application development, whereas the PowerShell scripting language is designed around scripting and its peculiarities.
    - WorldMaker 10y ago
      It's about like asking why would you use F# or (Iron)Python over C#? Different syntaxes have different strengths/weaknesses and the trade-offs can target different use cases and needs. At the end of the day it's whatever makes you (feel) productive. In terms of specifics, PowerShell's strengths over C# for scripting are particularly in PowerShell's the ability to succinctly navigate hierarchies (folders, but also other folder-like trees) in a way reminiscent of shells from time immemorial, as well as to easily interleave native binary calls (and pipes/redirects/captures). Some of it is the difference between grabbing C# binding for libgit off NuGet, LINQing my way through a the git DAG for the information I need versus running `git show xyz` or `git describe` directly in a shell and capturing that into a variable or piping that to whatever my next steps are. Depending on my level of abstraction and how often that script is called and if I'm paid to write that script or it is getting in the way of what I'm actually trying to work on, I use a different tool for the job.
int_handler 10y ago
Except Powershell isn't a real shell in the same way that cmd or any of the POSIX shells are. It's a REPL for a language running on the .NET VM. I'm neither a fan of the language nor having to wait several seconds due to the latency of having to start the .NET VM when you start posh.
- majkinetor 10y ago
  With nano server speed is optimised. It starts under 500ms. It has too, otherwise it would be slower then docker run.
- majkinetor 10y ago
  With nano server speed is optimised. It starts under 500ms. It has too, otherwise it would be slower then docker run.
- ygra 10y ago
  What is a shell for you then? If the defining characteristic is that it's not written in a managed language, well, okay, but I don't think many people share that sentiment. I have observed the several seconds startup time last with PowerShell v2 or so and that was not the time needed for the CLR to start, but rather PowerShell which was slow to start. v5.1 starts instantly here and the only slow thing about it is my profile, which admittedly does a bunch of things that take time (it's not yet at a point where it's annoying me so much that I edit it, and I can start typing commands during that time anyway (considering that I often spend more time thinking about what to write that's okay)).
  - flukus 10y ago
    > What is a shell for you then? A way to execute programs. The parent is right, powershell is more like a REPL to execute .net code. It's still no where near as good as a unix environment.
    - pjmlp 10y ago
      Says the one that never used a Xerox PARC like OS in anger. A GUI workstation using a REPL for scripting/automatic is so much powerful than a plain UNIX shell.
random_upvoter 10y ago
Many people are put off by Powershell because they believe that 20 years of experience in bash or CMD will allow them just fire up Powershell and get by. You will not get by. There's a good amount of gotchas and you will get stuck on some unexpected behavior within minutes. The thing is, if you want to use Powershell you do need to spend a few days just learning Powershell and nothing else. I have the impression some people don't want to do the effort. It's a pity because it truly is vastly better than any other shell in existence.
freehunter 10y ago
I haven't used Powershell since Windows 7, but at least back then it was super slow to start. cmd.exe opens immediately, like a normal terminal emulator. Powershell took several seconds to open. At least for me, if I'm opening the command line it's to get something done quicker and easier than I could with the GUI. Powershell wasn't that, at least on Windows 7.
- ygra 10y ago
  Windows 7 shipped with PowerShell v2. So yes, back then it was slow. It's not anymore. Side note: A terminal emulator is completely different from a shell (and on Windows (prior to 10 at least) there wasn't such a thing, but rather the console, which did not emulate a terminal).
- greggyb 10y ago
  Just for your reference, I've got Windows 10 and Powershell 5.1 running on an SSD (probably the only hardware that matters for program launch, really). I can hit Win-X-I and start typing commands as fast as possible and Powershell is up instantly and I've never missed initial characters on a command. For interactive use, it's always there and up quickly. This is in contrast to the typical start menu search which takes about a second before it registers keystrokes and I'm always searching for something missing the first few letters of the file or executable name.
bloblaw 10y ago
Helge Klein wrote an excellent article "What I Hate About PowerShell": https://helgeklein.com/blog/2014/11/hate-powershell/ https://helgeklein.com/blog/2014/11/hate-powershell/ Be sure to read the comments where PowerShell guru Jeffrey Snover politely addresses them. I share many of these same frustrations that have prevented me from adopting it as a Windows scripting language. I use it when I have to, but I still will choose csharp compiled EXE's, vbscript, or even Py2Exe'd Python programs over PowerShell for sysadmin type tasks. I was in the audience at MS TechEd 2005 in Orlando and watched as Jeffrey Snover presented Monad and highlighted it's Perl, awk, sed, and unix influences. I was immediately impressed. However, PowerShell seems to best fit as a REPL shell, and for me, more mentally cumbersome than using csharp (which of course can technically do everything ps can). My gripes with PS are kind of minor (a bit like my dislike of Python's whitespace enforcement), but it's kind of like a death by a thousand annoyances with PowerShell for me. For example (stolen from Helge's article), these are some WTF's for me * Testing for string equality: "abc" -eq "abc" ( why isn't this "abc" == "abc" ) * Greater than: 8 -gt 6 ( why isn't this 8 > 6 ?) * Functions can only be used after being defined. Leading to scenarios where a script begins waaaay down at the bottom. * dynamic scoping: http://ig2600.blogspot.de/2010/01/powershell-is-dynamically-scoped-and.html http://ig2600.blogspot.de/2010/01/powershell-is-dynamically-... * No way to syntax check a PS script before it's run These aren't all major, but the last one is a show-stopper for me. If I'm running a script on a couple hundred thousand machines (and I have) I can't afford to have my script bail out on an unexpected code-path. I really like the idea of PowerShell, and I am honestly glad it exists, but I think it would benefit from some changes outlined in Helge's article. And this is why me, someone working professionally with Windows for over 15 years (sysadmin, developer, security) doesn't choose to use PowerShell very often.
- thoth 10y ago
  > * Greater than: 8 -gt 6 ( why isn't this 8 > 6 ?) Wouldn't that be ambiguous with ">" when used for redirecting IO?

josephcooney 10y ago

The horrible syntax of Powershell isn't something I can look past.

alkonaut 10y ago
I think it's fairly neat (I mean - for shell scripting not for interactive use). The problem with shells is that they want to do both. The alias system in PS tries to make it possible to use a more bash-like syntax in interactive and the verbose syntax in scripts, which is a good idea, but it's hard to get right.
- ygra 10y ago
  As someone who golfs in PowerShell and very frequently uses it interactively too, I think the complaints about lack of terseness are quite overblown. Aliases, parameter binding by position or pipeline, the ability to shorten parameter names as long as they remain unambiguous, parameter aliases – all features that are most important for interactive use. Apart from a few nagging things where parameter prefixes clash (gci -f matches Force and Filter) I think it's quite good. Besides, I gladly pay that little price for much improved readability, discoverability and memorability. No more pondering whether the -Recurse flag is -r or -R in this particular command, for example.
  - noinsight 10y ago
    Also, since PowerShell is able to tab-complete cmdlets, parameters, parameter values (when they're enumerable) and even object properties, you hardly have to type much most of the time. The only problem with the tab-completing is that since everything has a standard verb prefix, you always have to type the beginning of the cmdlet name.

pshposh 10y ago

PowerShell is almost like using the python interactive interpreter as your command line but better. I was convinced how cool it was when I could import a C# .dll and load the types into PowerShell. You can even just write C# 'inline' and it compiles it on the fly. It baffles me as well how many Windows people I work with ignore it almost.

NoGravitas 10y ago
This is really the best analogy to explain PowerShell to Unix people. PowerShell's sweet spot is really not interactive use, but sysadmin-type scripting. It's very much like using Python for sysadmin tasks.
- Too 10y ago
  So essentially it's a programming language? For "scripting", why would I use it over just plain c#?
  - paulmooreparks 10y ago
    Because C# is designed around application development, whereas the PowerShell scripting language is designed around scripting and its peculiarities.
  - WorldMaker 10y ago
    It's about like asking why would you use F# or (Iron)Python over C#? Different syntaxes have different strengths/weaknesses and the trade-offs can target different use cases and needs. At the end of the day it's whatever makes you (feel) productive. In terms of specifics, PowerShell's strengths over C# for scripting are particularly in PowerShell's the ability to succinctly navigate hierarchies (folders, but also other folder-like trees) in a way reminiscent of shells from time immemorial, as well as to easily interleave native binary calls (and pipes/redirects/captures). Some of it is the difference between grabbing C# binding for libgit off NuGet, LINQing my way through a the git DAG for the information I need versus running `git show xyz` or `git describe` directly in a shell and capturing that into a variable or piping that to whatever my next steps are. Depending on my level of abstraction and how often that script is called and if I'm paid to write that script or it is getting in the way of what I'm actually trying to work on, I use a different tool for the job.

int_handler 10y ago

Except Powershell isn't a real shell in the same way that cmd or any of the POSIX shells are. It's a REPL for a language running on the .NET VM. I'm neither a fan of the language nor having to wait several seconds due to the latency of having to start the .NET VM when you start posh.

majkinetor 10y ago
With nano server speed is optimised. It starts under 500ms. It has too, otherwise it would be slower then docker run.
majkinetor 10y ago
With nano server speed is optimised. It starts under 500ms. It has too, otherwise it would be slower then docker run.
ygra 10y ago
What is a shell for you then? If the defining characteristic is that it's not written in a managed language, well, okay, but I don't think many people share that sentiment. I have observed the several seconds startup time last with PowerShell v2 or so and that was not the time needed for the CLR to start, but rather PowerShell which was slow to start. v5.1 starts instantly here and the only slow thing about it is my profile, which admittedly does a bunch of things that take time (it's not yet at a point where it's annoying me so much that I edit it, and I can start typing commands during that time anyway (considering that I often spend more time thinking about what to write that's okay)).
- flukus 10y ago
  > What is a shell for you then? A way to execute programs. The parent is right, powershell is more like a REPL to execute .net code. It's still no where near as good as a unix environment.
  - pjmlp 10y ago
    Says the one that never used a Xerox PARC like OS in anger. A GUI workstation using a REPL for scripting/automatic is so much powerful than a plain UNIX shell.

random_upvoter 10y ago

Many people are put off by Powershell because they believe that 20 years of experience in bash or CMD will allow them just fire up Powershell and get by. You will not get by. There's a good amount of gotchas and you will get stuck on some unexpected behavior within minutes. The thing is, if you want to use Powershell you do need to spend a few days just learning Powershell and nothing else. I have the impression some people don't want to do the effort. It's a pity because it truly is vastly better than any other shell in existence.

freehunter 10y ago

I haven't used Powershell since Windows 7, but at least back then it was super slow to start. cmd.exe opens immediately, like a normal terminal emulator. Powershell took several seconds to open. At least for me, if I'm opening the command line it's to get something done quicker and easier than I could with the GUI. Powershell wasn't that, at least on Windows 7.

ygra 10y ago
Windows 7 shipped with PowerShell v2. So yes, back then it was slow. It's not anymore. Side note: A terminal emulator is completely different from a shell (and on Windows (prior to 10 at least) there wasn't such a thing, but rather the console, which did not emulate a terminal).
greggyb 10y ago
Just for your reference, I've got Windows 10 and Powershell 5.1 running on an SSD (probably the only hardware that matters for program launch, really). I can hit Win-X-I and start typing commands as fast as possible and Powershell is up instantly and I've never missed initial characters on a command. For interactive use, it's always there and up quickly. This is in contrast to the typical start menu search which takes about a second before it registers keystrokes and I'm always searching for something missing the first few letters of the file or executable name.

bloblaw 10y ago

Helge Klein wrote an excellent article "What I Hate About PowerShell": https://helgeklein.com/blog/2014/11/hate-powershell/ https://helgeklein.com/blog/2014/11/hate-powershell/ Be sure to read the comments where PowerShell guru Jeffrey Snover politely addresses them. I share many of these same frustrations that have prevented me from adopting it as a Windows scripting language. I use it when I have to, but I still will choose csharp compiled EXE's, vbscript, or even Py2Exe'd Python programs over PowerShell for sysadmin type tasks. I was in the audience at MS TechEd 2005 in Orlando and watched as Jeffrey Snover presented Monad and highlighted it's Perl, awk, sed, and unix influences. I was immediately impressed. However, PowerShell seems to best fit as a REPL shell, and for me, more mentally cumbersome than using csharp (which of course can technically do everything ps can). My gripes with PS are kind of minor (a bit like my dislike of Python's whitespace enforcement), but it's kind of like a death by a thousand annoyances with PowerShell for me. For example (stolen from Helge's article), these are some WTF's for me * Testing for string equality: "abc" -eq "abc" ( why isn't this "abc" == "abc" ) * Greater than: 8 -gt 6 ( why isn't this 8 > 6 ?) * Functions can only be used after being defined. Leading to scenarios where a script begins waaaay down at the bottom. * dynamic scoping: http://ig2600.blogspot.de/2010/01/powershell-is-dynamically-scoped-and.html http://ig2600.blogspot.de/2010/01/powershell-is-dynamically-... * No way to syntax check a PS script before it's run These aren't all major, but the last one is a show-stopper for me. If I'm running a script on a couple hundred thousand machines (and I have) I can't afford to have my script bail out on an unexpected code-path. I really like the idea of PowerShell, and I am honestly glad it exists, but I think it would benefit from some changes outlined in Helge's article. And this is why me, someone working professionally with Windows for over 15 years (sysadmin, developer, security) doesn't choose to use PowerShell very often.

thoth 10y ago
> * Greater than: 8 -gt 6 ( why isn't this 8 > 6 ?) Wouldn't that be ambiguous with ">" when used for redirecting IO?