Windows sysadmin here. PowerShell has been great for a long time, well, since at least v5.1, when they finally fixed many of the annoying issues and limitations of earlier versions. I practically live in it the whole day - 90%+ of my work life is in PowerShell these days.
But I question its utility on other platforms, because a lot of the things that makes PowerShell cool on Windows doesn't actually work in Linux or macOS.
Eg: Get-Service (and associated cmdlets). Very handy cmdlet that I use all the time on Windows. On Linux, you'd expect that it'd work with systemd units, but no, that command doesn't exist on the Linux version. Same with Get-NetAdapter, or Get-NetTCPConnection, or Get-Disk and so many other handy cmdlets that I use all the time on Windows, are all missing.
Yet, some cmdlets do exist, like Get-Process or Get-Uptime etc, so I don't understand why many of the commonly used Windows cmdlets haven't been ported over.
Another annoying quirk is how PowerShell on *nix hands off some of the built-in aliases to their native versions. Like on Windows, I always use 'ls' because ain't nobody got time to type Get-ChildItem. Unfortunately when I run this on *nix PS, it runs the native version. And this is a problem because when I pipe 'ls' into a for loop or another cmdlet for further processing, it naturally, doesn't work. To make things worse, this native-or-alias decision making isn't even consistent. Like 'pwd' for example actually runs the PowerShell version, whereas 'echo' runs the native version.
Basically, as much as I love PowerShell on Windows, on *nix it is very annoying to work with. I would much rather work with native *nix shells and scripting languages. And if I really wanted the structured output of PS, I would run Nushell instead, which is far more consistent and useful than the half-baked product that *nix PowerShell is.
You can fix that very easily in your linux profile (make ls call gci and not native tool). Just add alias in your profile. You cant really complain about the absence of some cmdlets on linux, and they are trivially easy to get implemented (or wrap native tools).
I shouldn't have to do Microsoft's job. My point is that they put out a half-baked, nerfed shell for Linux, which is not cool. If they really wanted PowerShell to be taken as a serious, cross-platform shell, they should aim for 1-1 parity with the Windows version, or at least close to it. It's been 6 years since v7 came out, they've had plenty of time to do it.
If you want me to fix up Microsoft's slop, I'd rather contribute to a proper indie FLOSS project, like Nushell or something.
It’s a mixed bag. There are some really nice things. Like how easy it’s to get tab-completion for custom scripts, scripts in general are a lot more readable than something like bash. I also like the ability to do advanced things by calling .NET stdlib.
On the other hand, the considerable slowness or JIT lag kills me. Same with the crazy verbosity of everything. You end up setting up so many aliases that your shell ends up being very very different from any other pwsh. I setup or expect a lot of aliases on bash too, but pwsh is multiple orders of magnitude that. Like I always hate when I ssh to a machine and something as simple as `ll` doesn’t work and I need to spell out `ls -alh`, but with pwsh it’s EVERYTHING. Until very recently simple things like -e didn’t exist.
I have only ever used Powershell when I had no other options, but a decent number of the APIs feel designed by someone who has never used a terminal. Like they were begrudgingly fulfilling the objective without ever imagining a real use-case.
Naturally, I cannot produce an example off hand, but I was pretty disappointed the last time I had to reach for it and found that a few "obvious" workflows seemed more hacky than I would have expected for a clean-slate terminal language design.
PowerShell always felt like it's optimized for scripting rather than interactive CLI/REPL use. It's great when the complexity of what you do warrants writing a script that can be debugged, tested, and reused... but then there are better scripting languages. What is good for REPL and one-liner juggling is usually bad for scripting and readability, and vice versa. Can't design for both.
From what I get, the Designer hated Bash specifically. (As some1 who had 2 use it, can related) The syntax confusing, clunky & slow.
Said guy then proceeds to build a Shell which is even slower, the Syntax more convoluted than anything else
I personally prefer nushell[0] over PowerShell for similar tasks. My main is still Fish, but I occasionally use nushell when interactively exploring structured data (e.g. JSON files because I always forget the jq syntax) and specific nushell scripts I have (e.g. finding all the available nodes with GPUs on a SLURM managed HPC printed as a pretty table), which I find much easier to write than bash/fish.
Powershell is great, however I've recently started using file based apps to replace some of the more complex powershell scripts. Top level programs in C#14 can make equivalent powershell functionality look a bit dated.
Powershell is still indispensable for things like deploying build artifacts to production servers. Anything where you need to provide a secure command link between two windows boxes.
Most of my GitHub actions are a thin yaml wrapper around az login and powershell session setup. From that point 99% of the magic resides in a proper C# codebase.
I recently installed Powershell 7 because apparently that is different than the powershell that comes with windows. It's great, but, now I have at least 3 different Powershells in my OS? Why? And they function very differently. I had to change all the defaults for opening a new terminal or new shell window in Windows because many of the defaults kept giving me one of the old powershells which I wouldnt figure out until my commands and scripts kept giving errors, since they use commands which only exist in Powershell 7. Cannot believe Microsoft decided to copy Python's original sin and create several conflicting, coexisting installations of the exact same thing, but different incompatible versions. Whyyyyyyyy
Regarding the article: Corbin Davenport is an amazing name. Nice article too.
>3 versions
NOO! Maybe there is one 5.x? You should get rid of these.
Version 1.0/2.0 is called 'WindowsPowershell' (powershell.exe), it's usually in your System32 for compatibility reason.
'PowerShell7' (pwsh.exe) is the modern one. It Imports most Modules/Scripts from the former, except for 3 Modules or so which are incompatible.
PS> Get-Help -Name 'InsertName' -Full
Shows the Help, can be Imported/Created via XML 4 New Modules
PS> Update-Help -UICulture en-US
Fetches & Installs Help Files in English
Powershell is so good that I find it strange it didn't get to be default at least in some Linux distributins (or some proper fork/redo of it). I even used it for integrative feautures for some of my state projects serving millions of user. The fact that I have proper language, designed for shell, very efficient, not needing an IDE or anything, is quite liberating.
If I am nitpicking, performance could be better, although MS did a lot in previous years and even that just in theory as I was never really blocked by that. But if it could be performance beast too, I would think we can stop researching new shells and just use it everyhwhere.
JSON support is amazing - you don't learn anything new like with jq, it just works. Selecting stuff is amazing, I love it more then SQL. HashTables are epic for configuration (you have a real language in it, unlike in lets say YAML).
Scripts that look horrible in bash are few lines of beautiful in pwsh.
If you didn't try it, or didn't give it a chance, you are missing out for sure.
All of the alternative shells are in a tough spot. Bash is lousy, but it is installed everywhere. If you are going to use an alternative, why not a more widespread tool (Python, Perl, etc) that can potentially do more than piping commands together.
I believe nushell is the closest Linuxy Powershell implementation with structured data.
I must ask, do you not find Powershell's commands to be too huge and unwieldy to easily type? Or do you use autocomplete often enough that having to write complex camel case with hyphens for every single command is not a problem? That's where I trip up when writing anything for Powershell.
Yup. IMO the syntax is unusably awful for interactive sessions. Scripting, where you want to come back a year later and tell at a glance what it's doing, sure. Not for daily driving though.
It feels like the difference between old-timey classical English vs street talk. "Greetings, dearest companion, how fare you this fine Autumnal day?" is a lot of syllables for someone you're familiar with. "Hey! Enjoying the day?" says the same thing, but conversational. There's a time and place for the former, mainly when writing dialog set in 1500 or something. I'd much rather say the latter when bumping into my neighbor at the cofee shop. Similarly, I could see why someone might want to write
Get-ChildItem -Filter *.txt -Force
in a script so that it's clear-ish what that means later, but if I'm spending my time in a terminal, I'd vastly rather learn what
ls -la *.txt
means. It's terse to the point of inscrutability, and not beginner friendly at all, but once you type it a few thousand times it's second nature.
All things considered, I'll stick to Fish, thanks.
Edit: Related, but once I learned how Unix shells typically expand globs, that feels like the right layer for handling that and similar other things. "ls" doesn't know what a glob is. When you type "ls -la .txt", the shell* expands that into a list of matching files, like "ls -la foo.txt bar.txt baz.txt", then "ls" operates on each one of those in turn. You don't have to teach every program how to interpret globs. The shell has to learn that, once, then every other program automatically benefits from it. Type "echo *.txt" and you'll see the list of matching names. Echo has no idea what that means. It only knows that it got a list of worlds to write out with no idea where it came from. I think Bash/zsh/fish/etc. do this the right way, and that implementing that in every tool is the wrong way. It just feels weird and inefficient and prone to have odd, subtle deifferences.
My favorite PowerShell feature was barely mentioned: structured output!
Life is too short for parsing ad-hoc data formats from the 80s, and the "everything is a string" approach from *nix is a major contributor for the unreliability of shell scripts.
Part of setting up a new Windows or Linux machine for me is installing the latest PowerShell 7+.
My $PROFILE has custom modules that comprise ~9,000 lines of PowerShell. Anything "script-y" that I think I'll do more than a few times becomes a new function in one of those modules.
On Windows, I haven't used `cmd.exe` in at least a decade.
And part of my root `AGENTS.md` is "Please use PowerShell when generating scripts, unless I specifically ask for a different language."
Works a treat.
Once you get used to passing objects between commands - not just text - the thought of using a Unix-y shell feels like visiting the past.
PS is really powerful for Windows OS level concepts and enterprise software that have good modules (AD, IIS, Citrix). However it has so many semantics that can burn you; non-strict mode, implicit type conversion, ordered null checks [1], not to mention the amount of boilerplate in a module and the runtime overhead. At a certain scale/complexity you need to graduate to using C# and .NET.
I like Powershell but what's funny is you can now write single file C# scripts and run them from the dotnet command. No need for a solution or anything. Actually pretty nice for shell scripting now.
I find that PowerShell's syntax choices and verboseness make it just as cryptic as bash. "Okay, now we Get-Object... Ah crap, that's not it, what was it again? Ah yes, Select-Object... Okay now we pass that into Call-WebRequest... Wait that's not it either...".
The language designers managed to introduce the ambiguity of natural language into a shell scripting language. As a developer, I think that it makes PS wildly unergonomic and I find it easier to remember bash/Linux idiosyncrasies.
Introducing natural language uncertainties into a scripting language reminds me of AppleScript, which used almost entirely English words (mainly in sentences or at least verb phrases), but was nonetheless notably definitely not English. It was quite possible to forget at times which English verbs were language keywords and which weren't.
If I remember correctly, AppleScript was inspired by HyperTalk, which also mainly used English keywords in English-inspired syntax, but most HyperTalk wasn't valid AppleScript, and vice versa.
I have to admit it's better than scripting in Bash, but in my personal opinion that's a bar so low it's on the ground. Don't get me wrong, I'm grateful that shell scripting is a thing. But my policy for a decade has been that when I need any logic more complex than a simple string matching in an `if`, I should back away from the computer and then rewrite it in a reasonable scripting language.
Powershell is definitely a reasonable scripting language; it's mainly its verbose command names and new-to-me syntax that have made me put off learning it so far. I suspect that it looks more familiar and welcoming to .NET devs though.
Perl python tcl have been around for over 30 years. Anyone writing in bash/sh etc is producing unmaintainable line noise (and I was a perl and APL programmer)
Yes, since 7.3. But in that typical verbose and awkward PowerShell way. My quip about PowerShell is that if they called it PowerScript, you'd realize it was bad Python.
Great tool for Windows admins who haven't realized they can write quick and dirty C# scripts cross platform for a decade now.
Comparing to Bash is cheating, though. Try comparing it to Python. We don't need to have one tool for every task. On Linux we have always had support for multiple scripting languages. Use the right one for the job.
I use Powershell a fair bit, Powershell is not good. I can see why people delude themselves into thinking its good: it does in fact let you administer systems, and it lets you avoid the pitfalls of stringly-typed scripting like bash or batch files.
But being technically capable of something and being good at something are different.
Powershell tried so hard to be user friendly that it wrapped around and ended up being user hostile. There are far too many footguns and "magic" features that do nothing but sit around and wait for you to forget about them so they can break everything.
Just look at the comparison -eq as an example. First off, this is the same syntax powershell uses for named function arguments. Why on earth would you do this? Because operators like this exist, I now need to ask myself "is this a named function argument, or was the script author trying to use an operator here?" for EVERY NAMED ARGUMENT. But wait! That's not actually true! After all, powershell has two ways to call functions. Because powershell is like the red-headed stepchild of the other dotnet languages, when you want to call functions on assemblies, you can use a more conventional
[complex.syntax]::F(x, y)
So there you can use normal named arguments without having to second guess what they are right? Haha no jk powershell doesn't have a syntax for calling a C# function with named arguments, you just have to work out the positions and pass null (sorry, I mean [type]::Missing) in for any optional named parameters you didn't mean to supply a value for.
ANYWAY, back to the -eq operator. You might THINK that an equality comparison operator would return a boolean, but that is because you are not as smart as the PowerShell devs. The powershell devs know that an -eq operator should actually act like a filter if the left hand side is a list, returning the elements of the list that match the right hand side. Now in my head, this is the most astonishing behavior (least astonishing is just returning false if the types don't match, next up is a list of {true, false, ...} that comes from from mapping the comparison across the list), but that is because I am not as smart as Bill Gates.
Now you could maybe defend this behavior if it were easy to keep track of your types in powershell. But powershell actively makes this more difficult by doing things like automatically converting [int] into plain int when the array only has one item in it! So because powershell tries to be helpful and give -eq more power, then also tries to be helpful by unwrapping your one-item-lists because surely that's what you want, you can very quickly find yourself in a situation where you the scriptor are finding bizarre errors caused by having -eq insert lists of things where you expected booleans to be.
This kind of combinatorial-inconvenience is pervasive in powershell.
I'm all for "lets make an object-oriented scripting language", but there are so many unforced errors in the powershell language design that its hard to recommend.
Been using oh-my-posh in powershell, and some aliases to map commands for my old linux sysadmin brain. Everything mostly works to get the job done, even got vi and scp. Its just another tab in my windows terminal with my ubuntu tabs.
Yeah, you're not the first to discover this, but I'm curious how you'll feel in a few years. I recall three years ago my wife got a new gamer laptop and had nothing to do with her old one. I don't game, but got curious about playing around with Hyper-V. Packer at the time had no working builder for it, so I figured I'd make my own to create Linux VM images I could run on Windows, sort of "roll your own WSL." I quickly discovered PowerShell and unexpectedly fell in love with it. It only took me a few hours to have a working implementation roughly identical in function to Packer but without having to write any compiled code at all. It was pure PowerShell modules. This was before LLMs. I wrote it all myself, in a language I'd never used before, using documentation I had to search the web for using a plain search engine, and it still only took a few hours and did exactly what I wanted.
It didn't revolutionize my life, though. Three years later, I no longer use Windows for anything and revert to plain POSIX shell whenever possible for all scripting, largely for ecosystem reasons. Everyone else I work with is using that. I'd analogize this to challenges living downtown in the middle of a busy city. My roads are terrible, largely because they're so patchwork due to utilities and construction teams needing to tear out pieces, fix or add something underground to accomodate new building, then put the road back together again. It means you'll have 30 meters of regular concrete, then 10 meters of asphalt, then 20 meters of some pebbles in glue looking monstrosity. It works well enough for cars with large rubber tires and suspension systems, but it's hell for skateboarding. Go out to the suburbs where the entire road is all the same substance and it's smooth sailing.
Hacker News and the web more generally seems like these discussions about tooling and dev experience end up dominated by solo developers. If you're the only person working on a project, let alone these days with LLMs where half the breathless posts are about software where you're not only the sole developer but also the sole user, do whatever you want. It's like moving all the furniture around in your room every single day when you live alone. Go for it. But if you have a spouse, whether or not your new design is better than the old one, that's kind of rude. When you're part of a team, you have to eventually settle on all doing roughly similar, predictable things so you're not disrupting everyone else's workflows and expectations, even if those roughly similar, predictable things are suboptimal and there's a better way.
Windows sysadmin here. PowerShell has been great for a long time, well, since at least v5.1, when they finally fixed many of the annoying issues and limitations of earlier versions. I practically live in it the whole day - 90%+ of my work life is in PowerShell these days.
But I question its utility on other platforms, because a lot of the things that makes PowerShell cool on Windows doesn't actually work in Linux or macOS.
Eg: Get-Service (and associated cmdlets). Very handy cmdlet that I use all the time on Windows. On Linux, you'd expect that it'd work with systemd units, but no, that command doesn't exist on the Linux version. Same with Get-NetAdapter, or Get-NetTCPConnection, or Get-Disk and so many other handy cmdlets that I use all the time on Windows, are all missing.
Yet, some cmdlets do exist, like Get-Process or Get-Uptime etc, so I don't understand why many of the commonly used Windows cmdlets haven't been ported over.
Another annoying quirk is how PowerShell on *nix hands off some of the built-in aliases to their native versions. Like on Windows, I always use 'ls' because ain't nobody got time to type Get-ChildItem. Unfortunately when I run this on *nix PS, it runs the native version. And this is a problem because when I pipe 'ls' into a for loop or another cmdlet for further processing, it naturally, doesn't work. To make things worse, this native-or-alias decision making isn't even consistent. Like 'pwd' for example actually runs the PowerShell version, whereas 'echo' runs the native version.
Basically, as much as I love PowerShell on Windows, on *nix it is very annoying to work with. I would much rather work with native *nix shells and scripting languages. And if I really wanted the structured output of PS, I would run Nushell instead, which is far more consistent and useful than the half-baked product that *nix PowerShell is.
You can fix that very easily in your linux profile (make ls call gci and not native tool). Just add alias in your profile. You cant really complain about the absence of some cmdlets on linux, and they are trivially easy to get implemented (or wrap native tools).
I shouldn't have to do Microsoft's job. My point is that they put out a half-baked, nerfed shell for Linux, which is not cool. If they really wanted PowerShell to be taken as a serious, cross-platform shell, they should aim for 1-1 parity with the Windows version, or at least close to it. It's been 6 years since v7 came out, they've had plenty of time to do it.
If you want me to fix up Microsoft's slop, I'd rather contribute to a proper indie FLOSS project, like Nushell or something.
Deployment, deployment, deployment.
The web was successful because the installation cost was 0.
That is my only complaint really. Lets make it there... I beleive main offender is .net, but also main feature enabler.
There’s also gci and dir. Both work as an alias for Get-ChildItem in all supported platforms. No need to use ls.
ls is one letter shorter, and it's part of my muscle memory.
It’s a mixed bag. There are some really nice things. Like how easy it’s to get tab-completion for custom scripts, scripts in general are a lot more readable than something like bash. I also like the ability to do advanced things by calling .NET stdlib.
On the other hand, the considerable slowness or JIT lag kills me. Same with the crazy verbosity of everything. You end up setting up so many aliases that your shell ends up being very very different from any other pwsh. I setup or expect a lot of aliases on bash too, but pwsh is multiple orders of magnitude that. Like I always hate when I ssh to a machine and something as simple as `ll` doesn’t work and I need to spell out `ls -alh`, but with pwsh it’s EVERYTHING. Until very recently simple things like -e didn’t exist.
But the slowness is what really kills me.
I have only ever used Powershell when I had no other options, but a decent number of the APIs feel designed by someone who has never used a terminal. Like they were begrudgingly fulfilling the objective without ever imagining a real use-case.
Naturally, I cannot produce an example off hand, but I was pretty disappointed the last time I had to reach for it and found that a few "obvious" workflows seemed more hacky than I would have expected for a clean-slate terminal language design.
PowerShell always felt like it's optimized for scripting rather than interactive CLI/REPL use. It's great when the complexity of what you do warrants writing a script that can be debugged, tested, and reused... but then there are better scripting languages. What is good for REPL and one-liner juggling is usually bad for scripting and readability, and vice versa. Can't design for both.
I'm sure there are uglier incantations, but I recently discovered this is the correct way to run a traceroute in powershell
Test-NetConnection -ComputerName dns.google -TraceRoute
I got cobol fingers reading that
A common PowerShell complaint, personally I find PowerShell usually takes less keystrokes because the tab completion is flawless.
From what I get, the Designer hated Bash specifically. (As some1 who had 2 use it, can related) The syntax confusing, clunky & slow. Said guy then proceeds to build a Shell which is even slower, the Syntax more convoluted than anything else
What do you compare it with? Because bash is just terrible.
I personally prefer nushell[0] over PowerShell for similar tasks. My main is still Fish, but I occasionally use nushell when interactively exploring structured data (e.g. JSON files because I always forget the jq syntax) and specific nushell scripts I have (e.g. finding all the available nodes with GPUs on a SLURM managed HPC printed as a pretty table), which I find much easier to write than bash/fish.
0: https://www.nushell.sh/
Powershell is great, however I've recently started using file based apps to replace some of the more complex powershell scripts. Top level programs in C#14 can make equivalent powershell functionality look a bit dated.
Powershell is still indispensable for things like deploying build artifacts to production servers. Anything where you need to provide a secure command link between two windows boxes.
Most of my GitHub actions are a thin yaml wrapper around az login and powershell session setup. From that point 99% of the magic resides in a proper C# codebase.
I recently installed Powershell 7 because apparently that is different than the powershell that comes with windows. It's great, but, now I have at least 3 different Powershells in my OS? Why? And they function very differently. I had to change all the defaults for opening a new terminal or new shell window in Windows because many of the defaults kept giving me one of the old powershells which I wouldnt figure out until my commands and scripts kept giving errors, since they use commands which only exist in Powershell 7. Cannot believe Microsoft decided to copy Python's original sin and create several conflicting, coexisting installations of the exact same thing, but different incompatible versions. Whyyyyyyyy
Regarding the article: Corbin Davenport is an amazing name. Nice article too.
>3 versions NOO! Maybe there is one 5.x? You should get rid of these. Version 1.0/2.0 is called 'WindowsPowershell' (powershell.exe), it's usually in your System32 for compatibility reason. 'PowerShell7' (pwsh.exe) is the modern one. It Imports most Modules/Scripts from the former, except for 3 Modules or so which are incompatible.
PS> Get-Help -Name 'InsertName' -Full Shows the Help, can be Imported/Created via XML 4 New Modules PS> Update-Help -UICulture en-US Fetches & Installs Help Files in English
Hope that helps!
> It's great, but, now I have at least 3 different Powershells in my OS? Why?
Have you never used a Linux distro? I always end up with two windows managers, two login managers, 2-3 shells, 2-3 package managers and what not.
Powershell is so good that I find it strange it didn't get to be default at least in some Linux distributins (or some proper fork/redo of it). I even used it for integrative feautures for some of my state projects serving millions of user. The fact that I have proper language, designed for shell, very efficient, not needing an IDE or anything, is quite liberating.
I use it for all kinds of stuff. Here is an example that creates MusicBrainz collection from my local audio folder, solving the browsers proof of work in between: https://github.com/majkinetor/musicbrainz-userscripts/tree/m...
If I am nitpicking, performance could be better, although MS did a lot in previous years and even that just in theory as I was never really blocked by that. But if it could be performance beast too, I would think we can stop researching new shells and just use it everyhwhere.
JSON support is amazing - you don't learn anything new like with jq, it just works. Selecting stuff is amazing, I love it more then SQL. HashTables are epic for configuration (you have a real language in it, unlike in lets say YAML).
Scripts that look horrible in bash are few lines of beautiful in pwsh.
If you didn't try it, or didn't give it a chance, you are missing out for sure.
All of the alternative shells are in a tough spot. Bash is lousy, but it is installed everywhere. If you are going to use an alternative, why not a more widespread tool (Python, Perl, etc) that can potentially do more than piping commands together.
I believe nushell is the closest Linuxy Powershell implementation with structured data.
https://www.nushell.sh/
Python etc are not shell languages, so ergonomy suffers. Nu is good start, but far from there
I must ask, do you not find Powershell's commands to be too huge and unwieldy to easily type? Or do you use autocomplete often enough that having to write complex camel case with hyphens for every single command is not a problem? That's where I trip up when writing anything for Powershell.
Yup. IMO the syntax is unusably awful for interactive sessions. Scripting, where you want to come back a year later and tell at a glance what it's doing, sure. Not for daily driving though.
It feels like the difference between old-timey classical English vs street talk. "Greetings, dearest companion, how fare you this fine Autumnal day?" is a lot of syllables for someone you're familiar with. "Hey! Enjoying the day?" says the same thing, but conversational. There's a time and place for the former, mainly when writing dialog set in 1500 or something. I'd much rather say the latter when bumping into my neighbor at the cofee shop. Similarly, I could see why someone might want to write
in a script so that it's clear-ish what that means later, but if I'm spending my time in a terminal, I'd vastly rather learn what means. It's terse to the point of inscrutability, and not beginner friendly at all, but once you type it a few thousand times it's second nature.All things considered, I'll stick to Fish, thanks.
Edit: Related, but once I learned how Unix shells typically expand globs, that feels like the right layer for handling that and similar other things. "ls" doesn't know what a glob is. When you type "ls -la .txt", the shell* expands that into a list of matching files, like "ls -la foo.txt bar.txt baz.txt", then "ls" operates on each one of those in turn. You don't have to teach every program how to interpret globs. The shell has to learn that, once, then every other program automatically benefits from it. Type "echo *.txt" and you'll see the list of matching names. Echo has no idea what that means. It only knows that it got a list of worlds to write out with no idea where it came from. I think Bash/zsh/fish/etc. do this the right way, and that implementing that in every tool is the wrong way. It just feels weird and inefficient and prone to have odd, subtle deifferences.
In practice you use aliases instead of the full name.
It's not really a fit culturally. For example the syntax aesthetics are offputting for people coming from *ix.
My favorite PowerShell feature was barely mentioned: structured output!
Life is too short for parsing ad-hoc data formats from the 80s, and the "everything is a string" approach from *nix is a major contributor for the unreliability of shell scripts.
Part of setting up a new Windows or Linux machine for me is installing the latest PowerShell 7+.
My $PROFILE has custom modules that comprise ~9,000 lines of PowerShell. Anything "script-y" that I think I'll do more than a few times becomes a new function in one of those modules.
On Windows, I haven't used `cmd.exe` in at least a decade.
And part of my root `AGENTS.md` is "Please use PowerShell when generating scripts, unless I specifically ask for a different language."
Works a treat.
Once you get used to passing objects between commands - not just text - the thought of using a Unix-y shell feels like visiting the past.
I've written a lot of powershell in my time..
PS is really powerful for Windows OS level concepts and enterprise software that have good modules (AD, IIS, Citrix). However it has so many semantics that can burn you; non-strict mode, implicit type conversion, ordered null checks [1], not to mention the amount of boilerplate in a module and the runtime overhead. At a certain scale/complexity you need to graduate to using C# and .NET.
[1] https://learn.microsoft.com/en-us/powershell/utility-modules...
I like Powershell but what's funny is you can now write single file C# scripts and run them from the dotnet command. No need for a solution or anything. Actually pretty nice for shell scripting now.
PowerShell is nice. It also reads well. What does sed, tar xvf, jq curl -k actually _do_?
And then passing text lines with > like a caveman. Does bash not have the concept of objects?
You write Invoke-WebRequest and it invokes a web request. Easy.
I find that PowerShell's syntax choices and verboseness make it just as cryptic as bash. "Okay, now we Get-Object... Ah crap, that's not it, what was it again? Ah yes, Select-Object... Okay now we pass that into Call-WebRequest... Wait that's not it either...".
The language designers managed to introduce the ambiguity of natural language into a shell scripting language. As a developer, I think that it makes PS wildly unergonomic and I find it easier to remember bash/Linux idiosyncrasies.
Introducing natural language uncertainties into a scripting language reminds me of AppleScript, which used almost entirely English words (mainly in sentences or at least verb phrases), but was nonetheless notably definitely not English. It was quite possible to forget at times which English verbs were language keywords and which weren't.
If I remember correctly, AppleScript was inspired by HyperTalk, which also mainly used English keywords in English-inspired syntax, but most HyperTalk wasn't valid AppleScript, and vice versa.
unlike macos's curl, powershell's curl alias for Invoke-WebRequest checks the revoke list and will protect you from mitmproxy --emudhra
Unfortunately, it's not cURL. Not even cURL for Windows. It's build against the Schannel library. That is curl.exe, not iwr. Stemberg wrote a Blogpost you can find here https://daniel.haxx.se/blog/2023/04/24/deleting-system32curl...
No Idea what MacOS ships with but I'd mistrust that. But if you're running shell scripts...
Why doesn't curl check revoke list.
i don't know, man. i don't know.
I have to admit it's better than scripting in Bash, but in my personal opinion that's a bar so low it's on the ground. Don't get me wrong, I'm grateful that shell scripting is a thing. But my policy for a decade has been that when I need any logic more complex than a simple string matching in an `if`, I should back away from the computer and then rewrite it in a reasonable scripting language.
Powershell is definitely a reasonable scripting language; it's mainly its verbose command names and new-to-me syntax that have made me put off learning it so far. I suspect that it looks more familiar and welcoming to .NET devs though.
Only a decade ?
Perl python tcl have been around for over 30 years. Anyone writing in bash/sh etc is producing unmaintainable line noise (and I was a perl and APL programmer)
Does it have automatic error handling, so that if one command fails, the whole script fails too? Last time I tried it, I needed to write
after each command.Yes, since 7.3. But in that typical verbose and awkward PowerShell way. My quip about PowerShell is that if they called it PowerScript, you'd realize it was bad Python.
Great tool for Windows admins who haven't realized they can write quick and dirty C# scripts cross platform for a decade now.
Comparing to Bash is cheating, though. Try comparing it to Python. We don't need to have one tool for every task. On Linux we have always had support for multiple scripting languages. Use the right one for the job.
I use Powershell a fair bit, Powershell is not good. I can see why people delude themselves into thinking its good: it does in fact let you administer systems, and it lets you avoid the pitfalls of stringly-typed scripting like bash or batch files.
But being technically capable of something and being good at something are different.
Powershell tried so hard to be user friendly that it wrapped around and ended up being user hostile. There are far too many footguns and "magic" features that do nothing but sit around and wait for you to forget about them so they can break everything.
Just look at the comparison -eq as an example. First off, this is the same syntax powershell uses for named function arguments. Why on earth would you do this? Because operators like this exist, I now need to ask myself "is this a named function argument, or was the script author trying to use an operator here?" for EVERY NAMED ARGUMENT. But wait! That's not actually true! After all, powershell has two ways to call functions. Because powershell is like the red-headed stepchild of the other dotnet languages, when you want to call functions on assemblies, you can use a more conventional
[complex.syntax]::F(x, y)
So there you can use normal named arguments without having to second guess what they are right? Haha no jk powershell doesn't have a syntax for calling a C# function with named arguments, you just have to work out the positions and pass null (sorry, I mean [type]::Missing) in for any optional named parameters you didn't mean to supply a value for.
ANYWAY, back to the -eq operator. You might THINK that an equality comparison operator would return a boolean, but that is because you are not as smart as the PowerShell devs. The powershell devs know that an -eq operator should actually act like a filter if the left hand side is a list, returning the elements of the list that match the right hand side. Now in my head, this is the most astonishing behavior (least astonishing is just returning false if the types don't match, next up is a list of {true, false, ...} that comes from from mapping the comparison across the list), but that is because I am not as smart as Bill Gates.
Now you could maybe defend this behavior if it were easy to keep track of your types in powershell. But powershell actively makes this more difficult by doing things like automatically converting [int] into plain int when the array only has one item in it! So because powershell tries to be helpful and give -eq more power, then also tries to be helpful by unwrapping your one-item-lists because surely that's what you want, you can very quickly find yourself in a situation where you the scriptor are finding bizarre errors caused by having -eq insert lists of things where you expected booleans to be.
This kind of combinatorial-inconvenience is pervasive in powershell.
I'm all for "lets make an object-oriented scripting language", but there are so many unforced errors in the powershell language design that its hard to recommend.
Been using oh-my-posh in powershell, and some aliases to map commands for my old linux sysadmin brain. Everything mostly works to get the job done, even got vi and scp. Its just another tab in my windows terminal with my ubuntu tabs.
Yeah, you're not the first to discover this, but I'm curious how you'll feel in a few years. I recall three years ago my wife got a new gamer laptop and had nothing to do with her old one. I don't game, but got curious about playing around with Hyper-V. Packer at the time had no working builder for it, so I figured I'd make my own to create Linux VM images I could run on Windows, sort of "roll your own WSL." I quickly discovered PowerShell and unexpectedly fell in love with it. It only took me a few hours to have a working implementation roughly identical in function to Packer but without having to write any compiled code at all. It was pure PowerShell modules. This was before LLMs. I wrote it all myself, in a language I'd never used before, using documentation I had to search the web for using a plain search engine, and it still only took a few hours and did exactly what I wanted.
It didn't revolutionize my life, though. Three years later, I no longer use Windows for anything and revert to plain POSIX shell whenever possible for all scripting, largely for ecosystem reasons. Everyone else I work with is using that. I'd analogize this to challenges living downtown in the middle of a busy city. My roads are terrible, largely because they're so patchwork due to utilities and construction teams needing to tear out pieces, fix or add something underground to accomodate new building, then put the road back together again. It means you'll have 30 meters of regular concrete, then 10 meters of asphalt, then 20 meters of some pebbles in glue looking monstrosity. It works well enough for cars with large rubber tires and suspension systems, but it's hell for skateboarding. Go out to the suburbs where the entire road is all the same substance and it's smooth sailing.
Hacker News and the web more generally seems like these discussions about tooling and dev experience end up dominated by solo developers. If you're the only person working on a project, let alone these days with LLMs where half the breathless posts are about software where you're not only the sole developer but also the sole user, do whatever you want. It's like moving all the furniture around in your room every single day when you live alone. Go for it. But if you have a spouse, whether or not your new design is better than the old one, that's kind of rude. When you're part of a team, you have to eventually settle on all doing roughly similar, predictable things so you're not disrupting everyone else's workflows and expectations, even if those roughly similar, predictable things are suboptimal and there's a better way.