I started reading this article not knowing anything about powershell, and finished horrified by the issues he tried to dispel in it. No remoting, no scripting? Are they serious?
In defense of PowerShell
51–60 of 82 posts
Re: In defense of PowerShell
#52I dislike windows (and by extension, powershell) because a solution such as changing the port the webserver runs on looks something like: New-ItemProperty IIS:\sites\DemoSite -name bindings -value @{protocol="http";bindingInformation=":8081:"} http://www.iis.net/learn/manage/powershell/powershell-snap-i... What did I just modify? Is it persisted to the hard disk? How do i back that up? How do I revert the change? How…
So how would you accomplish the same task on Linux using bash? What script would you write to set the web server's port to 1234?
Re: In defense of PowerShell
#53> I’m willing to admit that PowerShell isn’t obviously better as a shell than something like bash, but it’s unquestionably a better language to use for scripting. There's a missing "on Windows" here. Sure, PowerShell is clearly a tool designed for the Windows environment. And if you're a Windows system administrator, it has more tools and glue for that environment. You could use PowerShell to replace things that you'…
I've lived in both the windows and linux/unix worlds and I will say that powershell is a better scripting language than bash. Bash is ok, but powershell is nicer. Powershell is sort of like python in that it tends to force down a path of doing things in a certain way.
Powershell isn't just "more tools and glue for windows stuff", it's a different way of doing things. In powershell you get named command-line parameters for free, that's a huge win. You get usage messages and simplified man-page help baked into the way things work, that's also huge. In powershell you don't just work with text, you work with objects, which pass along the pipeline. That means that instead of using sed and awk to muck up the output of some other script you can just use simple select, where, and format commands. This is incredibly powerful and an area where linux has fallen behind.
I like linux a lot, but this attitude of sneering down at windows and powershell merely because it's not linux is amateurish and parochial. People should be thinking about adapting the innovations that powershell has made and building on them instead of looking at it as some bizarre alien beast that will never be relevant to them.
Re: In defense of PowerShell
#54I started off as a PowerShell fan, but my introductory experience has been pretty poor. A little while back, I tried testing the output of a sorting algorithm with PowerShell. I wrote a line of bash to check my results:
diff get-content output.txt | foreach-object { [Int] $_ } | sort-object | out-file -encoding ascii sorted.txt
compare-object (get-content output.txt) (get-content sorted.txt)
You go read Microsoft tutorials [1] and they tell you to use Get-Content (cat) and Compare-Object (diff) like this for comparing files, but what they don't tell you is that order is ignored. Given how often I see the above code cited online for comparing files [2][3], I'm not sure that many people actually understand this.
I still haven't actually figured out how you properly compare files with PowerShell. I call fc.exe now, but its output is pretty gnarly so all I use is the return value.
[1] https://technet.microsoft.com/en-us/library/Ee156812.aspx [2] http://blogs.technet.com/b/heyscriptingguy/archive/2015/04/0... [3] http://serverfault.com/questions/5598/how-do-i-diff-two-text...
Re: In defense of PowerShell
#55> I’m willing to admit that PowerShell isn’t obviously better as a shell than something like bash, but it’s unquestionably a better language to use for scripting. There's a missing "on Windows" here. Sure, PowerShell is clearly a tool designed for the Windows environment. And if you're a Windows system administrator, it has more tools and glue for that environment. You could use PowerShell to replace things that you'…
If you take away the platform and command differences, then Bash is a worse scripting language than Powershell. Bash is a rough programming language to work in. This whole comment about "on Windows" is completely beside the point. And the impedance mismatch, as you said, was already commented about in the article.
> Bash is a worse scripting language than Powershell
Debatable, and certainly not "unquestionably" as the article suggests. You could certainly make the argument, but you don't get to drop the mic afterward.
Re: In defense of PowerShell
#56> I’m willing to admit that PowerShell isn’t obviously better as a shell than something like bash, but it’s unquestionably a better language to use for scripting. There's a missing "on Windows" here. Sure, PowerShell is clearly a tool designed for the Windows environment. And if you're a Windows system administrator, it has more tools and glue for that environment. You could use PowerShell to replace things that you'…
I've lived in both the windows and linux/unix worlds and I will say that powershell is a better scripting language than bash. Bash is ok, but powershell is nicer. Powershell is sort of like python in that it tends to force down a path of doing things in a certain way. Powershell isn't just "more tools and glue for windows stuff", it's a different way of doing things. In powershell you get named command-line parameter…
I'm not sneering at PowerShell because it's not Linux. And I think it's an impressive model. It's certainly a different way of doing things, and it's worth looking at and learning from.
But Powershell people dismiss the bash and Linux model of "everything's a file", too, the same way others dismiss the Powershell model. They're different; neither is "unquestionably" better for all cases.
Personally, once I start wanting stateful objects I can pass around to multiple methods, I switch from Bash to Python or Rust. I don't think Bash fits that use case well either, but that's not the only use case around.
Re: In defense of PowerShell
#57It worse than that, the misunderstanding that is. I live and breathe Linux. But Powershell is so far ahead of bash for text and object manipulation, it's not really even a close call.
That's an interesting claim, care to back it? P.S. *nix shell != bash, there's zsh and fish that are light years ahead re: tab completion and other general niceties.
Powershell data is not just plain-text, it's all objects. On *nix when you run "ls -l" you get text. On powershell when you run "gci" you get objects. But the objects are nicely formatted automatically for you when they hit stdout so it ends up looking the same.
On powershell if I want to find a list of files that are more than 100k in size I can just do "gci | where Length -gt 100000". If I want to see the top 10 processes that have the most handles open I just run "get-process | sort handles -desc | select -first 10". That way of interacting with things extends all the way through every aspect of powershell and it's incredibly potent. If I want to query a bunch of build jobs from a service I can just create a simple couple line script that talks to a web service and returns queries. Then I can use the built in select, where, format, etc. commands to get at the data I want. I can filter by jobs that have failed, I can filter by jobs of a certain type, or that ran on one machine. All of that is basically free on powershell, it's just baked into the way everything works. It saves you from all the ridiculous overhead of using perl, sed, awk, etc. just to get at the data you want.
Aside from that, with powershell you get things like man-page-style help and usage messages, named parameters, parameter type checking, etc. at very low cost, as just the natural way of doing things.
The Unix philosophy has always been about having small tools that you can use together to get big stuff done, powershell very much embodies that philosophy.
Re: In defense of PowerShell
#58Earlier quoted context omitted.
Some of us do, but we've given up trying to expose HN to the shell. The anti-Microsoft culture that built up in the late 1990s and early 2000s has too much inertia on HN to overcome by occasional articles.
Keep in mind that much of what seemingly makes Powershell so great on Windows is inapplicable in a Unix shell environment. So there's still some juvenile "M$ hyuck hycuk" nonsense, but there's also some pretty spot-on discussion of the difficulty of trying to move tools between very different systems.
[deleted]
Re: In defense of PowerShell
#59The real "gotcha" for Powershell, for me, is the huge differences between versions. As the author mentions, v3 is much better than v1. The original version is pretty bad. A lot of parsing cmdlets don't work right. And a lot of the really useful ones aren't included, which also blocks some of the cool cmdlets you can download and install.
Having to port a script from Powershell v5 to Powershell v2 is dumb, but sadly necessary. Usually I'll write a script on the oldest server in the farm to ensure interoperability. But often the workarounds for v2 break v5's implementation of select-string or other parsing tools.
And this doesn't get into remote execution or remote script enablement, which are both separate. Powershell fragmentation is a serious problem that complicates Windows adminstration and use of this powerful tool.
Re: In defense of PowerShell
#60Powershell definitely has its quirks, and unfortunately one of its best features - powerful remote administration - is also painful to configure and troubleshoot and is often unreliable and slow.
I wish the team in charge of Powershell would take a page from the Python community and adopt an opinionated, "one right way to do everything" stance. For anyone using or looking in to Powershell, here are a few best practices I've compiled:
- Concurrency in Powershell is generally ugly and painful. Background jobs are OK if you want to background something while you're working at the command line (although you could just open another window) but they're a pain to use in scripts, plus they're very heavyweight and slow if you need any semblance of performance. There are other ways of doing concurrency but they are not well documented and are fairly messy. Events/observer pattern is possible but weird. If you need concurrency, head for C#.
- Handling exceptions is way better than it used to be (trap), but still annoying. For your sanity and everyone else's, set $ErrorActionPreference = "Stop" at the top of every script, along with Set-StrictMode -Version Latest.
- Keep track of what you're outputting to your pipeline - anything that generates output that you're not capturing into a variable gets thrown in the pipeline, which can wreak havoc, especially if you end up with different types of objects being emitted. Sprinkle Out-Null around to avoid this. Combine multiple data fields into a new psobject if necessary (this is also good for scripts that output a bunch of information at the end).
- Don't use Write-Host - it's not output and thus can't be redirected. Use Write-Verbose frequently, and consider adding $VerbosePreference = 'Continue' in your profile to see verbose output all the time.
- If you need to access a SQL database, use ADO.NET. Invoke-SqlCmd and the rest of the sqlps module are a mess, at least the last time I looked. You can use sqlcmd.exe too but then you're back to text output.
- Add this to your profile. With this, any time you run something at the command line, it will be stored in $LastObject. I always forget to store stuff in a variable.
function Out-Default { $input | Tee-Object -var global:LastObject | Microsoft.PowreShell.Core\out-default }