I Like Powershell

https://buttondown.email/hillelwayne/archive/i-really-like-powershell/

by BerislavLopac • 3 years ago

55 59 3 years ago

Well, I don't, and I'm a Windows fanboy. So, why, exactly none of you ask:

1. The PowerShell separation of, what on *ix* systems is stdout and stderr, doesn't really work. Want to know whether your invocation of a PowerShell command worked? Well, it might be that the error stream has content, otherwise check the warning stream, otherwise check the regular output stream, and see if it contains an error-message-like-ish string

2. Continuing on this theme, just 'give me all the output, regardless of type/class, from this command' is just plain impossible. You want to see what this command would print on a terminal? Good luck with that!

3. Serializing PowerShell output to JSON (which, naively, you would assume would be sort-of reliable) generates heaps of PS*-specific junk. Just the common '|fl XXX' expression will trigger this

4. Even commands that appear to be successful, may in fact have failed. The Azure commandlets are especially guilty of this. Remove a load balancer NAT rule? Sure, we'll pretend to do that! Except, nothing happens, and you'll need a support ticket to actually modify your configuration

majkinetor11• 3 years ago

Yeah, lets take 4 random things and yell around it sux.

PreInternet012• 3 years ago

That's a remarkably insightful rebuttal. I sure see the errors of my way now. Except I'm not really sure whether these are in the Output, Error, Warning, Verbose or Debug stream, so...

pathartl2• 3 years ago

The only point I would raise is that #1 isn't reliable on any system that has stdout/stderr. For most of the MS-created modules this is implemented correctly. You also have the ability to catch and throw exceptions... foreign to people who live in scripts but essential for people who have programming experience.

whodev• 3 years ago

What do you mean with #3? A command like below runs perfectly fine with no PS* specific junk.

``` > Get-Process | Select -Last 5 Name,ProcessName,Company,Path | ConvertTo-Json [ { "Name": "winlogon", "ProcessName": "winlogon", "Company": null, "Path": null }, { "Name": "WmiPrvSE", "ProcessName": "WmiPrvSE", "Company": null, "Path": null }, { "Name": "WMIRegistrationService", "ProcessName": "WMIRegistrationService", "Company": null, "Path": null }, { "Name": "Zoom", "ProcessName": "Zoom", "Company": "Zoom Video Communications, Inc.", "Path": "C:\\Users\\user\\AppData\\Roaming\\Zoom\\bin\\Zoom.exe" }, { "Name": "Zoom", "ProcessName": "Zoom", "Company": "Zoom Video Communications, Inc.", "Path": "C:\\Users\\user\\AppData\\Roaming\\Zoom\\bin\\Zoom.exe" } ] ```

And when you say "Just the common '|fl XXX' expression will trigger this" does that mean you are doing this `<command> | fl X | ConvertTo-Json`? Because if so, that's why your getting all the PS specific junk.

mst2• 3 years ago

IIRC HN really wants an indented paragraph for code blocks, your ``` did not go precisely to plan, I don't think - if you indent:

  ```
    foo
    bar
  ```

it'll be happier.

gtsteve• 3 years ago

1. You check `$LastExitCode`, similar to `$?`. You can also catch exceptions when dealing with real Powershell commands.

2. Try piping your output through `| Format-List -Property *`. This isn't very discoverable really.

3. Try selecting the properties you want: `| select Name, ID, Etc`

4. This is the fault of the module developer, not Powershell. You can also write bad software in C.

psd15• 3 years ago

`$?` works and is more reliable. Git notoriously gives non-zero exit codes for success conditions

psd15• 3 years ago

1. Native PS is easy. Binary commands are no harder than on any other platform, but I find $? to be reliable. Now you know.

2. Pipe to Out-String. Now you know.

3. Format commands generate console-host-specific markup. You would never pipe through FL to json, that's a bizarre thing to do. You're complaining that the boot doesn't fit on your head. If you want to filter properties, use select or generate new objects in foreach.

4. Fair, but not a Powershell issue

Pompidou• 3 years ago

I would agree, but by default powershell start and interactions are so slow (a boring unacceptable slowness!), that I prefer to use windows command or tcl wish for every day usages.

majkinetor11• 3 years ago

While it can be faster, you must be using Commodore 64 or something. Or you have Defender running or something... It starts instantly, anything else is your local problem. Please stop spreading nonsence and learn to use your machine.

Havoc2• 3 years ago

It's slow AF on multiple machines my side too so he is not alone.

learn to use your machine.

https://news.ycombinator.com/newsguidelines.html

pxc4• 3 years ago

Where I work, my laptop runs a bunch of agents I have no choice about, some of which are related to Windows Defender.

A new PowerShell session takes anywhere from *five to thirty seconds* just to give me a prompt I can type at.

Blame it on the other software if you want, but PowerShell isn't just a little slow. It's hundreds of times slower than any interactive shell should be.

The part of my PowerShell profile that takes the most time to execute is removing all of the fake, useless aliases for Unix commands that PowerShell bundles and refuses to remove.

psd15• 3 years ago

Pwsh starts on my machine in 400-500ms. Far slower than I'd like. That is with no profile.

I am a wizard. My profile is my power. With great care and sacrifice I've got it down to about 2s and I just have to load less-commonly-used stuff ad-hoc.

I have a 3900X with 64gb of ram and a recent ssd.

Powershell startup time is the number one problem with the tool, GP is correct.

eek2121• 3 years ago

I don’t. Reason: too wordy. Reminds me of Java.

majkinetor11• 3 years ago

RTFM

smackeyacky• 3 years ago

I always felt that Powershell was a solid indication that the whole GUI-isation of the world that started with such a bang in the 1980s has been an impossible task to complete.

For something as complicated as Windows Server, there is not enough time to build GUI screens and OLE/COM/DCOM interfaces for every little flag, function or feature. Microsoft must have realised this quite some time ago.

The evidence? That even Windows 11 contains ancient, crufty GUI screens from Windows XP and older. It turned out the Unix guys were right all along. There is nothing wrong with the core of Windows as an operating system, but the baggage it carries mostly due to all those failed GUI screens makes it inferior in practice to Unix based systems.

I have one powershell script I use, which is something that manipulates an Outlook mailbox. It's unreliable (thanks to Outlook) but again demonstrates what a pointless idea the entire Powershell project was and to a certain extent what a dead end things like systemd will eventually end up being.

yarg• 3 years ago

If you're building screens for every set of configurations that you're defining (and doing it a lot) then you're doing it wrong.

If you can specify some sort of schema for configuration in general, then the screens can generally be generated.

You generally don't want or need to display different instances of the same sort of configuration property in fundamentally different ways.

I think that what you get from a (decent) GUI is discoverability of features, whereas what you get with the CL is specificity.

The former makes computers accessible to the masses, the latter provides power to administrators.

kjellsbells• 3 years ago

Reading this discussion I'm wryly reminded of IBM AIX and it's smitty tool. It let you administer AIX unix from a GUI, but always emitted the equivalent CLI command, as if GUIs were just something it hoped youd eventually grow out of.

hdaz0017• 3 years ago

{{(({{ CoNgRaTs On LiKiNg PoWeRsHeLl... It'S 2023 AnD HaS AlWaYs MaDe My EyEs BlEeD... }}))}}

scripts are some 100x longer and normally break due to everything or anything changing...

psd15• 3 years ago

I just PR'd into a project that's a kludgy mess of bash.

You can code-golf in Powershell. There are terse aliases. But generally the community doesn't do that. Looking at some of the bash garbage I've been subjected to, I'm glad.

"normally break" yeah bad devs use bash too, trust me.

Havoc2• 3 years ago

I don't mind powershell as such but the windows ecosystem it is in kills any desire I have to learn powershell. The "python" command in powershell triggering an app store popup even with python installed is the one that pushed me over the edge. I'll just remote into a *nix machine...

pxc4• 3 years ago

That's actually a Windows thing, not a PowerShell-specific thing. The Microsoft Store app generates a stub executable called python.exe and puts it on your PATH. It'll get picked up whether you're in PowerShell, CMD, or MSYS2 Bash. It's basically the same kind of thing as Xcode's git stub on macOS (which I also find odious).

The feature is called 'executable aliases', in case you want something to Google to find out how to disable it.

CoolCold• 3 years ago

whoa! something new and makes some sense for newbies

pathartl2• 3 years ago

Powershell has grown on me. Over time I've worn down and started utilizing my Windows install in the Windows way. I think Powershell is a well overlooked feature of the platform, to the point where I now have moved a lot of my scripts/automations on my home server (Linux based) from bash/js/.NET 7 binaries to Powershell Core.

Big asterisk, my day job is as a .NET/C# developer. So much of Powershell does feel like a .NET wrapper or C#-lite, and that's not necessarily a bad thing. It lends itself very well to feeling like a traditional programming language. Hell, it even has a debugger! My only real complaint about it and adoption thus far is the release management. Windows 11 _still_ ships with 5.1, and 7 is leagues ahead in terms of performance and features.

majkinetor11• 3 years ago

I cant understand why so many pwsh haters. Its literary light years away from any other shell. The comments are ridiculous as usual. This kind of behavior should be examined at adequate academia (when amazing thing is made and people think its shit, there shoud be some name for it).

fuzzfactor2• 3 years ago

when amazing thing is made and people think its shit, there shoud be some name for it

I would call it un-called-for criticism.

But I don't want to be too critical . . .

Mountain_Skies• 3 years ago

For people who are accustomed to the *nix world, PowerShell can feel like the uncanny valley of shells.

majkinetor11• 3 years ago

Thats because they are hypocrites. You can't separate *nix shell from awk, less, grep, jq, insert-whatever-little-tool-with-random-argument-parser-here. Once you do that, it feels like the uncanny universe of organic horrors.

Don't get me wrong. Yey for the *nix stuff, I am huge fan. We wouldn't be here if that was absent. I am not working for MS or anybody that have stakes here. Its simply no comparrison.

jasoneckert• 3 years ago

As an ancient UNIX person, I've always loved PowerShell from the start. I remember the first time I played around with the first version that wasn't a download (2). I wanted to see how it dealt with objects, so I ran something simple:

$ui = (Get-Host).UI.RawUI

$ui | Get-Member (to see the methods and attributes available)

$ui.WindowTitle = "Hello World Window!"

After that, I was hooked. PowerShell providers and modules are incredibly useful, as is piping output to Out-GridView. Later versions have introduced more cmdlets that, quite honestly, everyone should use instead of DOS commands (e.g., Get-NetIPConfiguration instead of ipconfig). I do remember a bit of timing issues (often solved by inserting Start-Sleep) and other general flakiness like others have noted here, but the ones I've noticed were fixed in later versions.

deafpolygon• 3 years ago

I've been using some form of *nix since 1997? Pretty much since I had my first computer. I was very late to the party - didn't touch a computer until college! I've used Windows on and off throughout those years (gaming, mainly).

Using PS is a joy, I've re-written all of my usual utility stuff from bash/zsh to PS inside a few week, and managed to improve on a bunch that I didn't want to do before because bash is painful to debug/test/etc.

I rarely fire up WSL now, and it has replaced Python for my general utility scripting language.

Note: if anyone is reading this - if you're still using PS5 built into W11, then you owe it to yourself to install PS7 (it can be installed alongside 5). It is invoked via pwsh rather than powershell, and can be setup to use the same startup scripts as the default PS.

ggorlen4• 3 years ago

The author has a few good points. I want to love PS as well, but in practice it has too many gotchas and pitfalls that seem to pop up every time I write a script more than a few lines.

Sure, all languages have these, but the ones in PS feel nastier and more subtle than most, compounded by the fact that it's not a language I use more than once every few months and should be easy to pick up and put down.

Basic stuff like parens, commas, function calls, casting, variable interpolation and arrays are frequently surprising. Many behaviors fail silently.

For example, arrays with 1 element behave differently than arrays with 2+ elements. PS is "smart" and treats the 1-element array as a scalar. Why? I've wasted hours dealing with arrays in PowerShell.

See this post for a sampling of the problems: https://stackoverflow.com/a/69644807/6243352

Even without the gotchas, case insensitivity, optional abbreviations, optional parens, etc, make PS scripts harder to read and debug than they need to be. PS feels like a mashup of many of the most confusing parts of PHP and Perl and adds its own fresh mess on top. Adding parameters and resolving a few of Bash's failings isn't much of an achievement given ~20 years of time to design it properly. Neither language is as easy to work with as it should be.

Riverheart3• 3 years ago

If I had a nickel for every time I had to debug some crazy Bashism. PowerShell can be finicky at times but is a walk in the park compared to the alternatives. For basic stuff like if/else comparisons I don’t need to lookup how many parens or square brackets to use for strings or arithmetic or recall if 0/1 is true false or reverse. Maybe I should just compare “false”/“true” strings or use true/false commands instead which have their own issues.

PowerShell has real functions, not just exit codes and text streams so you can easily write maintainable scripts past 100 lines. It’s got a debugger. It’s got modules and a package gallery. It’s got autocomplete and help messages. It’s got try/catch/finally instead of traps. It’s got an optional type system so you can be as loose or strongly typed as you want. It’s cross platform so the Windows devs don’t get confused migrating to Linux. It’s got batteries included for everything between cmdlets and .net. Anything you can do in C# can be replicated. Sed/awk/Grep are nice but sometimes you just want structured data converted into an object to pass around functions instead of reinventing the wheel.

Case sensitivity is a feature, $foo and $Foo should be the same and if they’re not you should call it something different or invoke it differently. “$foo = new [foo]” separates variables from types. “$env:foo” namespaces your env vars. In Bash is FOO a var, constant or env var?

Good PowerShell is readable with little effort. Good Bash is readable with significant effort if you are familiar with Bash and the problem domain already.

ggorlen4• 3 years ago

Case sensitivity isn't a major deal, but it's another example of the designers trying too hard to be clever and "user friendly". A good scripting language should try to reduce friction relative to other programming languages, most of which are case sensitive.

I'd like to see a native OS scripting language that has a low bar of entry, isn't silent on undefined variables and other common mistakes, imposes syntactical consistency like Go or Python, has decent basic data structures and isn't riddled with pitfalls. PS isn't that language.

If Bash and PS were good, it'd be so much easier to bring non-programmers into the command line so they can automate tasks and hack on their systems. Unfortunately, these languages aren't doing that, much less passing the usability test with most programmers who'd just assume script with Py, Perl, JS, or whatever their preferred language is.

psd15• 3 years ago

Look up strict mode.

Array unrolling is a legitimate gripe. The design justification is that Powershell is pipeline-oriented. On occasions where you specifically need an array, either type your variable or use the array operator:

    [object[]]$foo = 42
    $foo = @(42)

ggorlen4• 3 years ago

Good point about strict mode. However, I've collected a few gotchas[1] that I don't think strict mode helps with (as seems to be the case with languages that offer strict mode, it's not enough). If you're curious and have time to take a look and let me know what I might have misunderstood, I'd appreciate it.

I think I'm missing which problem your code solves. There are a few array issues in my gotcha journal. Adding types like [object[][]] doesn't seem to help with getting PS to understand nested arrays with 1 element, for example, and $foo = @(42) is the array declaration syntax I usually use.

[1] https://gist.github.com/ggorlen/1e337f211f508124321c8bc7c1d2...

mlazos• 3 years ago

Powershell is incredibly powerful with | and %{} for transforming collections and SUPER simple .net integration. You can write commandlets in c#. It was one of the bright spots of my time at Microsoft.

zamalek• 3 years ago

I have used pwsh in depth in the past. 4-5 years ago when I was exclusively Windows, doing SharePoint, AD, Azure, etc. Also local utility scripts.

I have used bash in depth over the past year, I maintain the local dev cluster tooling at work (because nobody else wants to, see: bash). It's about 2kloc of pretty advanced bash.

While PowerShell is a terrible language, piping around text (or rather, let's face it, JSON) is objectively worse. I do feel more productive with the Bash language/syntax, but I have no faith in any code that I write. Bash is littered with footguns and odd behavior.

I have been learning nushell recently and have been greatly enjoying it. You get to pipe around structures, while avoiding the obnoxious PowerShell syntax. As an example from today, I was double-checking that some envars made it into a container image:

    skopeo inspect ... --format json | from json | each { |x| $x.Env }

Now that's certainly possible with bash and jq, but I'd probably be leaning on Google even after 1000s of hours of maintaining a bash behemoth.

eviks3• 3 years ago

You can do the default thing and write Get and press tab to cycle through things that start with Get.

Except Tab is a lateral pinky key press, one of the worst key presses out there

mst2• 3 years ago

It's also been the standard for that behaviour for shells and, well, lots of other things, for so long it won't change, and notice he also mentioned Ctrl-Space as an alternative.

Though my hands don't complain so long as I don't use a mouse, so YMMV.

jiggawatts• 3 years ago

An often overlooked aspect of the "vision" of PowerShell is that it is intended to be the back-end of a GUI console!

An good example is the Citrix management console. It is a very thin Windows GUI wrapper around a bunch of PowerShell modules. Literally everything it does, and everything it shows comes from PowerShell, not from direct API calls. When managing a Citrix farm remotely, it uses WinRM PowerShell remoting, not traditional COM+ RPC.

This is easy because:

1. The PowerShell runtime can be trivially embedded into any .NET app. It's just a reference and about 3 lines of biolerplate.

2. It runs "in-process", making it much faster than calling out to external shells.

3. The commands are (relatively) strongly typed, so there's no concerns about escaping, shell injection, or other similar security issues.

4. Outputs come back as lists of strongly typed C# objects, making them trivial to bind to grid views or other GUI user controls.

5. Even tree views are easy to wire up, because PowerShell has a concept of virtual "drive" providers that can wrap anything in a file/folder structure. You just write a generic "folder and item navigator" GUI control once and then you can use it with any number of providers for free.

The end-result looks like a traditional GUI, but basically guarantees that anything you can do in the GUI, you can also do in the shell. It's also ridiculously easy to add a "generate a script for this change" button, because it's just spitting out the internal representation!

badrabbit• 3 years ago

Powershell is well...powerful and I can't say much bad about it. Bash scripting can be a pain but I like using bash scripts to chain together io from installed programs, the same task is difficult in powershell. Powershell lets you do stuff nicely if you stick to powershell modules and .net stuff. It's not very nice when wrangling output from $randomprogram.

But regardless of platform I use bash or powershell usually for very small self-contained scripts and python for anything more extensive.

I always say powershell is more akin to python or perl than bash except python never got around to making repl into a shell interpreter or nice things like script signing enforcement.

IYasha• 3 years ago

(linux user): isn't Powershell that new slow as hell command prompt based on some .NET? No, thanks. It's just terrible as everything made of .NET.

tpoacher• 3 years ago

Nice article, and this is obviously a very specific nitpick from a single point in the article, but ...

ls --full-time | cut -d' ' -f6,7 # WRONG
If two “fields” have different lengths, ls will add spaces to the name of the smaller one to make the two line up, which will break cut -d' '. And in fact you can’t solve this at all with ls, you have to write stat -c %w. Text streams don’t compose.

I mean, ok, I get the point how he's saying Powershell has 'objects', but the example is super-contrived. All it takes to fix the offending 'padding spaces' is to remove them.

  ls --full-time | tr -s ' ' | cut -d' ' -f6-7

Moreover, that's not even "bash" you're comparing against, but 'coreutils'. If you really wanted to grab the output of 'ls' with pure bash then you'd probably go with something like this instead:

  ls --full-time | while read -r FIELD{1..8}; do echo "$FIELD6 $FIELD7"; done

which isn't exactly complicated either.

Otherwise, if the gripe is about the command you're using not being field based, then go ahead and use one that is, on data that supports it. This isn't exactly a language issue.

Case in point, if 'stat' is the right command to get that "field" for that "object type", then there you go. Nagging that if you don't use the right tool for the job will leave you with having to work around things, is not exactly the environment's fault.

Also, text streams absolutely do compose. It's just that the underlying type will always be a text stream. But composability is 100% the reason behind this in the first place.

I Like Powershell

Related Stories