Rendered at 20:31:37 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
d3Xt3r 4 days ago [-]
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.
CrimsonCape 3 days ago [-]
I know linux is prided for it's low-level C code, but linux is desperately missing an object-oriented API. C# flavor below:
var service = thisSystem.GetService("rss-news-feed");
service.SetRefresh(TimeSpan.FromHours(1));
service. //<----now we can autocomplete everything a service can do.
Edit: it's a travesty that OO get's shoehorned into architectural design of large systems whereas it would be ideally suited in a Nix-like API for interacting with operating systems which are 'solved'.
ktpsns 2 days ago [-]
This is not true. There is dbus these days. There was CORBA and friends in days when COM was new.
ofrzeta 3 days ago [-]
> On Linux, you'd expect that it'd work with systemd units
This seems quite hard to implement. There are also other init systems that PowerShell may chose to not support but then they'd need to add a disclaimer for supported systems. Also systemd is quite complex with its setup of user defined units, overlays etc.
d3Xt3r 2 days ago [-]
> There are also other init systems that PowerShell may chose to not support but then they'd need to add a disclaimer
That's not really a concern, I mean systemd is by far the most popular init system, and especially in a situation/environment where one might choose to run PowerShell it's highly unlikely that you'd be running any other init. Like if you're the kind who'd prefer dinit or S6 or something, you wouldn't even consider running a "bloated" shell like PowerShell in the first palace.
So there's no need to add a disclaimer. Microsoft can just deal with it the same way they deal with distro support - they officialy support Ubuntu but for others you're on your own, although they do provide tar.gz packages.
And yes, systemd is indeed quite complex but there's no reason it can't be translated across to PowerShell lingo, at least parts that makes sense.
They've had six+ years to do perfect this, which is plenty of time - if they were really serious in pitching PowerShell as a true cross-platform shell. But it seems like they don't really care, especially now that they've captured most Linux users by means of WSL2, so it makes more sense for them to invest in that rather than invest in cross-platform parity in PowerShell.
hulitu 2 days ago [-]
> Also systemd is quite complex with its setup of user defined units, overlays etc.
But Microsoft has the design documents, so it shouldn't be a problem to implement this functionality. /s
tressure 4 days ago [-]
There’s also gci and dir. Both work as an alias for Get-ChildItem in all supported platforms. No need to use ls.
d3Xt3r 4 days ago [-]
ls is one letter shorter, and it's part of my muscle memory.
majkinetor 4 days ago [-]
sal ls gci >> $PROFILE
its faster then this discussion.
d3Xt3r 4 days ago [-]
ls was just an example. There's tons more. I'm not going to test each and every command/alias/cmdlet and fix it so that it reaches parity with the Windows version. This is something Microsoft should have done so out of the box.
majkinetor 4 days ago [-]
You are aware that there exist people who can want the opposite?
You can ask AI now to do it for you, you can probably find easily something somebody already did. It would have been nice if MS offered something that people can choose to install, but its far from a deal breaker like you seem to make it to be.
There is nothing to test, you want collection of aliases, that is trivial.
As I said before, it's not just the aliases, it's all the cmdlets that are missing too, there's too many of them to list.
And why should I waste my AI tokens on fixing Microsoft's product? I'd much rather contribute my resources towards a fully open-source, indie project.
majkinetor 3 days ago [-]
Because you are making it better for us, non MS people (its also already fully open source). I cant understand this way of thinking. Companies are not good or evil, they are abstract entities with people behind them and tones of regular users around. Besides, no fatureset will ever fit everybody, customization is a thing.
hulitu 1 days ago [-]
> Companies are not good or evil, they are abstract entities
So that's why laws do not apply to them. (Except VW)
We shall fix that.
majkinetor 1 days ago [-]
We should but we probably wont. There is such thing in my country named something like "piercing the corporate veil", when the deeds are dimed so bad that state goes after owners, but it was never used in practice.
3 days ago [-]
majkinetor 4 days ago [-]
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).
d3Xt3r 4 days ago [-]
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.
majkinetor 4 days ago [-]
Such a drama without a reason.
Its not slop for one. Take a look at repo and its practices. Its mind blowing and predates AI.
Nushell is nice, but lets not get carried away - it is decade away from pwsh, and suffers from the same things you complained, with language and semantics that are not intutive as pwsh's and not nearly as complete. Besides, so many 3rd party supports pwsh like Sql Server, VMware etc.
I agree that MS should push it way more and make Linux variant even better. The problem is that pwsh hardly surived at MS (cudos to Snover for being stuborn and worked against his position at MS to make it happen), and that needs some opinionated people working in MS who can fight this battle (I could honestly dedicate my life to this, I offer my services, for both pwsh and Windows, Microsoft!).
oblio 4 days ago [-]
Deployment, deployment, deployment.
The web was successful because the installation cost was 0.
majkinetor 4 days ago [-]
That is my only complaint really. Lets make it there... I beleive main offender is .net, but also main feature enabler.
3eb7988a1663 4 days ago [-]
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.
orbital-decay 4 days ago [-]
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 ergonomics of one-liner juggling is usually bad for scripting and readability, and vice versa. Can't design for both.
Calculators had the same problem when they got too powerful for their own good and feature creep made them outgrow their use case in the world of personal computers (see TI or modern advanced calculator apps like Qualculate). They're pretty awkward compared to HPs that were designed for expressing a simple problem in fewest keystrokes with great attention to detail like interactive inversion and repetition.
retromagik 4 days ago [-]
I'm sure there are uglier incantations, but I recently discovered this is the correct way to run a traceroute in powershell
And you are wrong, who says that is the correct way. The correct way is the one that works
tnc dns.google -t
I didn't even have to look for the alias, there is standard naming for them.
Like I said before, people who complain just didn't RTFM and got out of their comfort zone.
beng-nl 4 days ago [-]
I got cobol fingers reading that
Dedime 4 days ago [-]
A common PowerShell complaint, personally I find PowerShell usually takes less keystrokes because the tab completion is flawless.
pjmlp 4 days ago [-]
Hardly makes sense as complaint when nowadays folks are writing book sized prompts to AI agents.
orbital-decay 4 days ago [-]
Book sized prompts are equally poor for interactive use, they're typically reused and iterated upon. They're more like scripts than commands.
pjmlp 4 days ago [-]
So a markdown file then, still much more letters than a common COBOL source file.
cherrychon 4 days ago [-]
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
majkinetor 4 days ago [-]
Its good to hate bash specifically. The language is so terrible, low on standards, bad discovery. The only good thing about bash is it is pre installed. Its not far away from batch (.bat).
bulbar 4 days ago [-]
What do you compare it with? Because bash is just terrible.
jval43 4 days ago [-]
I can't believe how this opinion got so popular, because I disagree completely with the Bash bashing.
I totally get it for people who only ever used .BAT files (our entire IT department at work). It must feel like a godsend to them. Bash of course never worked for these people; running it on Windows via MinGW/Cygwin is just a bad experience.
But the relentless bashing of Bash itself and the longstanding Linux (and Unix) ecosystem alternatives in general is unjustified in my opinion.
Bash itself is elegant, powerful and concise, and just works on Linux. You can write spaghetti code, but you don't have to. Readable scripts are just as easy. "Skill issue" if you will.
And yes, Bash-isms exist, and I got reminded of that fact when Ubuntu shipped Dash as the default /bin/sh shell for a while or when I'm on macOS. But it's really not a huge deal: just use the real !#/bin/bash and ignore the "um actually in Posix..." complainers on the internet.
I do appreciate that Windows finally has a capable scripting language, and while I don't like the lengthy syntax / cmdlets, I also see some benefits. But Bash is still great nonetheless.
t0mpr1c3 2 days ago [-]
bash is fine for simple text files. perl is a natural extension for structured data.
Using pwsh I can achieve in a few lines what previously would have required a perl script and bunch of IO and class definition boilerplate. It is powerful for interactive use. The verbosity is only a surface feature: the abbreviated aliases are discoverable.
Powershell and WSL are great features of modern Windows. Too bad about the Copilot-isation of everything.
16bitvoid 4 days ago [-]
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.
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.
cherrychon 4 days ago [-]
>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!
much-to-learn 2 days ago [-]
Also, if using winget, it will try to install the MSIX from the msstore if you don’t specify the source and/or installer. To make sure you install the msi, you want to use ‘winget install --id Microsoft.PowerShell --installer-type wix —source winget’. The MSIX will be called PowerShell7 in winget and the msi will be called PowerShell7-x64 and they will coexist without warning until it becomes an issue for you.
bulbar 4 days ago [-]
> 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.
jval43 4 days ago [-]
I want to see your 2-3 package managers :-) Unless you count apt, aptitude, apt-get etc separately.
One saving grace with Linux distros is that usually the maintainers package versions that are compatible with each other. So if you stay with the default repos things work.
But yeah once you install newer versions from non-distro repos it might be fine (e.g. git) or things will break in subtle ways.
Volundr 3 days ago [-]
I have Pacman, mise, and nix on mine
If that's a problem or not is a matter of perspective.
Brian_K_White 4 days ago [-]
This 30+ year linux user says you never have 2 or 3 different incompatible bash's.
You can have multiple different sh's, but you have to go out of your way to force them to be used. And evenn if you did, dash and ash and older versions of bash and sysv sh are a strict totally compatible subset of latest bash, and none ever has the problem of incompatible or missing modules or plugin library. Old scripts work in new bash.
The python to powershell comparison was valid. This false equivalence was not.
The fact that you can have 2 window managers is like having 2 mp3 players. It's not the critique at all.
esseph 3 days ago [-]
Sounds like a personal problem with indecision tbf :/
holysoles 4 days ago [-]
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.
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.
xp84 4 days ago [-]
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.
pasc1878 4 days ago [-]
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)
xp84 3 days ago [-]
Oh for sure. I just personally was foolish enough to keep writing nontrivial bash scripts until ~2017 or so.
SBArbeit 4 days ago [-]
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.
majkinetor 4 days ago [-]
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.
Schlagbohrer 4 days ago [-]
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.
kstrauser 4 days ago [-]
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.
Schlagbohrer 3 days ago [-]
> 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
Or with Boston compression active: "Heyhowarya"
__d 3 days ago [-]
VMS people, am I right in remembering that there’s a standard “library” which does globbing, so while it’s done in every tool, they at least do it consistently?
Unix used to have a glob command, rather than building it into the shells (and the C library). I think it was 7th edition that added it directly to Bourne shell.
lostmsu 3 days ago [-]
In terminal I would do
gci -F<tab> *.txt -force
In this particular case I would type the word force out but with other parameters starting with `f` I would just use <tab> until I get the right one.
majkinetor 4 days ago [-]
No. I use aliases so its as quick as with bash, but I am faster as I don't have to lookup for params due to fantastic discovery and usability features.
With longer commands, auto complete is also viable. I hate some long forms, like % vs ForEach-Object and ? vs Where-Object, its just ludicrious that someone would insisit in using full forms of those.
Things like `ps | ? name -like w*` or `1..10 | % { irm https://.../$_ }` can't really get shorter and I use them all the time
Auto complete on params is epic. Type -e and ctrl space to see all params starting with e along with their aliases. Verbosity is good thing in that case, as -ea doesn't mean much when you are new to this.
ps -e<CTRL+SPACE>
ErrorAction ea ErrorVariable ev
The verbose practice is not meant for interactive use, but for sharing scripts.
LeonB 4 days ago [-]
In practice you use aliases instead of the full name.
3eb7988a1663 4 days ago [-]
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.
Python etc are not shell languages, so ergonomy suffers. Nu is good start, but far from there
fulafel 4 days ago [-]
It's not really a fit culturally. For example the syntax aesthetics are offputting for people coming from *ix.
majkinetor 4 days ago [-]
That is just common invalid trope. You can make scripts look shorter and more "culturally fit" than bash. Its just that people prefer more verbose variants for some rasons (I don't). There are automatic converters too. The legit reason is to make script cross platform, as that is easier with verbose form.
globular-toast 4 days ago [-]
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.
t0mpr1c3 2 days ago [-]
Python isn't a shell
ibramGaunt 4 days ago [-]
A lot of the frustration I've seen with PowerShell from longtime Linux users is that there's an expectation that everything is a file in the linux/bash idiom, and can be interacted with that way (tangent, I think this is where a lot of vexation with systemd comes from), where Windows and the NT kernel enforce the concept of everything is an object.
It's a much more powerful system, but users who are used to being able to do, well, whatever they want with no rules get frustrated with the syntax and "correct way" to do a thing when you just want a stupid string (it's me I'm users). It's very similar to Rust in that way, where once you stop fighting the borrow checker life becomes so much easier; once you stop fighting the objects, you stop getting in your own way and it becomes a much more productive experience.
eddythompson80 4 days ago [-]
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.
bob1029 4 days ago [-]
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.
ruined 4 days ago [-]
unlike macos's curl, powershell's curl alias for Invoke-WebRequest checks the revoke list and will protect you from mitmproxy --emudhra
No Idea what MacOS ships with but I'd mistrust that. But if you're running shell scripts...
Superbowl5889 4 days ago [-]
Why doesn't curl check revoke list.
ruined 4 days ago [-]
i don't know, man. i don't know.
delis-thumbs-7e 4 days ago [-]
I think for few years MS has tried to be a bit more developer friendly. The Windows Terminal (and no, not what opens running Command Line or Powershell, it is a different application: https://en.wikipedia.org/wiki/Windows_Terminal) is kinda good actually. It’s not Alacritty, but a lot better than any previous terminal emulator. I have also poked around their developer tools and they do seem to make using windows a little less hellish experience: https://learn.microsoft.com/en-gb/windows/dev-environment/
And PS is pretty good, although I haven’t used used PS7 much (if it is a completely new application, why does it share a version number? And why does it not come as the default shell with Windows? Why do they have to make everything so confusing?). It is probably nicer for extended scripting than bash, but honestly I rather use Python for that. For windows admin stuff it is great, but mostly I work with network stuff and it is way too verbose to my taste for simple commands. ping is a lot easier to remember than Test-Connection. I reach for cmd commands like netsh int set ip rather than tab through the verbose syntax of PS for simple network commands. I know you can set up aliases and bash aliases like ls work, but I still feel it os pretty impractical for quick terminal work.
Using it on linux feels so blashemous that I will not entertain such vile and fevilish thoughts. I use linux to get away from the sinful awful things I must do for my livelihood, I tather not use Win applications on my own system unless I absolutely need to. For any serious scripting on Mac… Maybe just don’t?
lostmsu 3 days ago [-]
I stopped using Windows Terminal altogether because it somehow tends to crash the processes running inside its tabs. And I have a lot of terminals open.
An example issue: https://github.com/microsoft/terminal/issues/16363 . This exact error message with different codes happened to me across many machines at many different times. Never seen anything like that with the classic console host.
Panzerschrek 4 days ago [-]
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
if ($LastExitCode -ne 0)
after each command.
badlibrarian 4 days ago [-]
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.
stephbook 4 days ago [-]
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.
static_motion 4 days ago [-]
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.
schoen 4 days ago [-]
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.
rmeby 3 days ago [-]
There is a standard[0] you are ignoring either intentionally or out of ignorance. It is okay that you are used to Bash but please stop spreading false information about PowerShell.
It's not false information. I'm just saying it's as idiosyncratic as bash is (and no, defining its own special standard doesn't make it less so, it just makes its idiosyncracy well defined), and that I have a hard time agreeing with anyone who says that PowerShell's syntax is more intuitive than bash. You still need to learn the special naming scheme, same as needing to learn bash's own quirks. Someone who comes from bash to PS might not know about the existence of that "standard", and might fumble about as I described.
2d8a875f-39a2-4 4 days ago [-]
yeah there's a reason they call it POWERShell, not EasyShell, SimpleShell or IntuitiveShell.
Eye-bleed syntax, but I guess my agents don't mind that.
4 days ago [-]
4 days ago [-]
BoppreH 4 days ago [-]
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.
nonameiguess 4 days ago [-]
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.
tosti 3 days ago [-]
You've got to be kidding me with that syntax. Here's the script in Perl:
And have you seen errors in powershell? Bill Lumbergh would like such a verbose report, not me.
t0mpr1c3 2 days ago [-]
You can get a fairly long way with just bash and perl one-liners. I worked in data science in the 2000s, and this was the typical way I would merge .csv files and do other simple data manipulation tasks interactively.
It's not much fun, and the resulting code tends to be fragile. Every line ends up being piped through utilities like cut, join, awk, and jq.
IMO the structured output from pwsh makes those sort of tasks a great deal easier.
tosti 1 days ago [-]
I guess it depends on your view of "easier". You may prefer a scripting language that has everything under one roof (even a compiler!), while I very much prefer the pipeline approach (which has many different compilers).
IronWolve 4 days ago [-]
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.
bloaf 4 days ago [-]
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.
Brian_K_White 3 days ago [-]
This helpfulness reminds me of my new 4runner's transmission. It's not merely automatic, is a "learning" automatic, so it's behavior is always changing and never predictable.
It's always trying to adapt to the driver, but that is a fundamentally invalid concept.
I think there is (or should be) a principle that in any given system there can only be at most one spongy dynamic reactive element.
Everything else needs to be deterministic.
In a car, the human driver is unavoidably a spongy dynamic element, so the only slot available for one of those is already taken. You can't have both a driver trying to game the car and the car trying to game the driver at the same time.
t0mpr1c3 2 days ago [-]
You make some good points about the behavior of -eq.
I think these kind of trade offs are part of being a shell. Relaxing the type strictness is intended to make interactive use easier. It is debatable whether the additional complexity is justified.
It's still decent enough for scripting, and for anything beyond plumbing there is .NET
dexterlagan 4 days ago [-]
I can't believe Windows is the most popular OS in the world.
I can't believe people like ChatGPT.
I can't believe LLMs are getting smarter.
I can't believe some software is actually good.
I can't believe a corporation can make a good product.
Surprise! We're all just humans trying to be useful and happy, even CEOs!
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.
var service = thisSystem.GetService("rss-news-feed");
service.SetRefresh(TimeSpan.FromHours(1));
service. //<----now we can autocomplete everything a service can do.
Edit: it's a travesty that OO get's shoehorned into architectural design of large systems whereas it would be ideally suited in a Nix-like API for interacting with operating systems which are 'solved'.
This seems quite hard to implement. There are also other init systems that PowerShell may chose to not support but then they'd need to add a disclaimer for supported systems. Also systemd is quite complex with its setup of user defined units, overlays etc.
That's not really a concern, I mean systemd is by far the most popular init system, and especially in a situation/environment where one might choose to run PowerShell it's highly unlikely that you'd be running any other init. Like if you're the kind who'd prefer dinit or S6 or something, you wouldn't even consider running a "bloated" shell like PowerShell in the first palace.
So there's no need to add a disclaimer. Microsoft can just deal with it the same way they deal with distro support - they officialy support Ubuntu but for others you're on your own, although they do provide tar.gz packages.
And yes, systemd is indeed quite complex but there's no reason it can't be translated across to PowerShell lingo, at least parts that makes sense.
Eg:
And so on.They've had six+ years to do perfect this, which is plenty of time - if they were really serious in pitching PowerShell as a true cross-platform shell. But it seems like they don't really care, especially now that they've captured most Linux users by means of WSL2, so it makes more sense for them to invest in that rather than invest in cross-platform parity in PowerShell.
But Microsoft has the design documents, so it shouldn't be a problem to implement this functionality. /s
its faster then this discussion.
You can ask AI now to do it for you, you can probably find easily something somebody already did. It would have been nice if MS offered something that people can choose to install, but its far from a deal breaker like you seem to make it to be.
There is nothing to test, you want collection of aliases, that is trivial.
FWIW, they tried some things like https://github.com/PowerShell/Crescendo
And why should I waste my AI tokens on fixing Microsoft's product? I'd much rather contribute my resources towards a fully open-source, indie project.
So that's why laws do not apply to them. (Except VW)
We shall fix that.
If you want me to fix up Microsoft's slop, I'd rather contribute to a proper indie FLOSS project, like Nushell or something.
Its not slop for one. Take a look at repo and its practices. Its mind blowing and predates AI.
Nushell is nice, but lets not get carried away - it is decade away from pwsh, and suffers from the same things you complained, with language and semantics that are not intutive as pwsh's and not nearly as complete. Besides, so many 3rd party supports pwsh like Sql Server, VMware etc.
I agree that MS should push it way more and make Linux variant even better. The problem is that pwsh hardly surived at MS (cudos to Snover for being stuborn and worked against his position at MS to make it happen), and that needs some opinionated people working in MS who can fight this battle (I could honestly dedicate my life to this, I offer my services, for both pwsh and Windows, Microsoft!).
The web was successful because the installation cost was 0.
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.
Calculators had the same problem when they got too powerful for their own good and feature creep made them outgrow their use case in the world of personal computers (see TI or modern advanced calculator apps like Qualculate). They're pretty awkward compared to HPs that were designed for expressing a simple problem in fewest keystrokes with great attention to detail like interactive inversion and repetition.
Test-NetConnection -ComputerName dns.google -TraceRoute
Like I said before, people who complain just didn't RTFM and got out of their comfort zone.
I totally get it for people who only ever used .BAT files (our entire IT department at work). It must feel like a godsend to them. Bash of course never worked for these people; running it on Windows via MinGW/Cygwin is just a bad experience.
But the relentless bashing of Bash itself and the longstanding Linux (and Unix) ecosystem alternatives in general is unjustified in my opinion.
Bash itself is elegant, powerful and concise, and just works on Linux. You can write spaghetti code, but you don't have to. Readable scripts are just as easy. "Skill issue" if you will.
And yes, Bash-isms exist, and I got reminded of that fact when Ubuntu shipped Dash as the default /bin/sh shell for a while or when I'm on macOS. But it's really not a huge deal: just use the real !#/bin/bash and ignore the "um actually in Posix..." complainers on the internet.
I do appreciate that Windows finally has a capable scripting language, and while I don't like the lengthy syntax / cmdlets, I also see some benefits. But Bash is still great nonetheless.
Using pwsh I can achieve in a few lines what previously would have required a perl script and bunch of IO and class definition boilerplate. It is powerful for interactive use. The verbosity is only a surface feature: the abbreviated aliases are discoverable.
Powershell and WSL are great features of modern Windows. Too bad about the Copilot-isation of everything.
0: https://www.nushell.sh/
Regarding the article: Corbin Davenport is an amazing name. Nice article too.
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!
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.
One saving grace with Linux distros is that usually the maintainers package versions that are compatible with each other. So if you stay with the default repos things work.
But yeah once you install newer versions from non-distro repos it might be fine (e.g. git) or things will break in subtle ways.
If that's a problem or not is a matter of perspective.
You can have multiple different sh's, but you have to go out of your way to force them to be used. And evenn if you did, dash and ash and older versions of bash and sysv sh are a strict totally compatible subset of latest bash, and none ever has the problem of incompatible or missing modules or plugin library. Old scripts work in new bash.
The python to powershell comparison was valid. This false equivalence was not.
The fact that you can have 2 window managers is like having 2 mp3 players. It's not the critique at all.
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...
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)
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 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.
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.
Or with Boston compression active: "Heyhowarya"
Unix used to have a glob command, rather than building it into the shells (and the C library). I think it was 7th edition that added it directly to Bourne shell.
With longer commands, auto complete is also viable. I hate some long forms, like % vs ForEach-Object and ? vs Where-Object, its just ludicrious that someone would insisit in using full forms of those.
Things like `ps | ? name -like w*` or `1..10 | % { irm https://.../$_ }` can't really get shorter and I use them all the time
Auto complete on params is epic. Type -e and ctrl space to see all params starting with e along with their aliases. Verbosity is good thing in that case, as -ea doesn't mean much when you are new to this.
The verbose practice is not meant for interactive use, but for sharing scripts.I believe nushell is the closest Linuxy Powershell implementation with structured data.
https://www.nushell.sh/
It's a much more powerful system, but users who are used to being able to do, well, whatever they want with no rules get frustrated with the syntax and "correct way" to do a thing when you just want a stupid string (it's me I'm users). It's very similar to Rust in that way, where once you stop fighting the borrow checker life becomes so much easier; once you stop fighting the objects, you stop getting in your own way and it becomes a much more productive experience.
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.
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.
No Idea what MacOS ships with but I'd mistrust that. But if you're running shell scripts...
And PS is pretty good, although I haven’t used used PS7 much (if it is a completely new application, why does it share a version number? And why does it not come as the default shell with Windows? Why do they have to make everything so confusing?). It is probably nicer for extended scripting than bash, but honestly I rather use Python for that. For windows admin stuff it is great, but mostly I work with network stuff and it is way too verbose to my taste for simple commands. ping is a lot easier to remember than Test-Connection. I reach for cmd commands like netsh int set ip rather than tab through the verbose syntax of PS for simple network commands. I know you can set up aliases and bash aliases like ls work, but I still feel it os pretty impractical for quick terminal work.
Using it on linux feels so blashemous that I will not entertain such vile and fevilish thoughts. I use linux to get away from the sinful awful things I must do for my livelihood, I tather not use Win applications on my own system unless I absolutely need to. For any serious scripting on Mac… Maybe just don’t?
An example issue: https://github.com/microsoft/terminal/issues/16363 . This exact error message with different codes happened to me across many machines at many different times. Never seen anything like that with the classic console host.
Great tool for Windows admins who haven't realized they can write quick and dirty C# scripts cross platform for a decade now.
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.
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.
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.
[0] https://learn.microsoft.com/en-us/powershell/scripting/devel...
Eye-bleed syntax, but I guess my agents don't mind that.
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.
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.
It's not much fun, and the resulting code tends to be fragile. Every line ends up being piped through utilities like cut, join, awk, and jq.
IMO the structured output from pwsh makes those sort of tasks a great deal easier.
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.
It's always trying to adapt to the driver, but that is a fundamentally invalid concept.
I think there is (or should be) a principle that in any given system there can only be at most one spongy dynamic reactive element.
Everything else needs to be deterministic.
In a car, the human driver is unavoidably a spongy dynamic element, so the only slot available for one of those is already taken. You can't have both a driver trying to game the car and the car trying to game the driver at the same time.
I think these kind of trade offs are part of being a shell. Relaxing the type strictness is intended to make interactive use easier. It is debatable whether the additional complexity is justified.
It's still decent enough for scripting, and for anything beyond plumbing there is .NET