Hacker News Reader

Comment by neves | Hacker News Reader

I've always been curious to know. I am an experienced Bash developer, and when PowerShell was released, I was very excited. Finally, we would have a cool shell on Windows for development. However, since then, I've never managed to grok PowerShell and continue to use my good old Bash even on Windows.

What is the experience of other developers who are experts in both shells to compare them? Did PowerShell really fulfill the promise of being a more efficient and modern shell? Or people just use it because it is already installed and better than CMD?

View on HN

I've done a lot of Bash, read some books about it, I'm a firm believer that nobody should be writing anything complex in bash. Above the ballpark of 50 lines I consider it a code smell. I have this web page saved up in case I ever need to convince anyone of this.

http://mywiki.wooledge.org/BashPitfalls

I used Powershell recently and not having to wrangle with text (commands return objects) makes it a much easier scripting language, and command line language.

The fact that they have an official way to handle argument parsing is excellent, everything is unified and the commandline window is able to have autocompletion for literally every option of everything. Bash could never even dream of having that. It is incredible and makes you extremely productive.

But type coercion manages to introduce new ways to create bugs that Bash didn't have.

Honestly at this point I prefer PWSH but still kinda dislike both. I'm waiting for the new natural evolution.

I forgot but one thing I also liked that made me go "Why would bash not have that?" is having a dedicated verbose,info,warn,error,debug output and a glob star *> to redirect everything. It's nice not having verbose text polluting stderr.

> I have this web page saved up in case I ever need to convince anyone of this... http://mywiki.wooledge.org/BashPitfalls

This is a great list of pitfalls, absolutely, but they are more an argument for integrating shellcheck into your IDE than avoiding bash, IMHO!

I know, I know, possible religious war, but I find that bash+shellcheck is far more often the right toolset than switching languages to avoid the pitfalls.

The immense power and expressiveness and immediacy of bash makes so many programs and so much prototype->PoC->MVP progression so easy and effortless that it is worthwhile having tooling to catch the worst of the warts.

Add shunit or similar and I You can have a really nice experience (imho).

Many of these pitfalls are not the shell, but external programs (sed, xargs, grep, etc).

I know it ends up in the same terminology bucket for the public consciousness as "CLI stuff", but there is a separation and understanding this separation is crucial for writing good sh.

The problem actually lies in bash+coreutils being some sort of de-facto standard for command line stuff. The way bash+coreutils evolved was mostly for autotools and not for humans. This ecosystem could be much better.

PowerShell has more builtins, so it relies less on external commands, therefore it is less vulnerable to pitfalls due to mismatches between different programs.

For mismatches, custom scripts & commands in Powershell benefit from having a standard way to take input, and because the output is not text, you're also safer on that end

But in the end really it doesn't matter in whose end of the kingdom the bugs come from. What matters is that's how people write Bash.

It works very well if you're all inside powershell.

Try this exercise: make a .BAT invoke a powershell script that invokes another .BAT passing parameters containing double quotes inside. It just can't be done reliably. The .BAT is only just an example, any param passing to/from powershell (outside powershells internals) is a nightmare.

In bash, this kind of interaction is commonplace. You can make `find` generate shell snippets for you, and pipe the generate shell commands into another interpreter instance seamlessly.

Think of the sheer amount of software the uses the shell this way and you never notice. That npm script that just passes parameters along is relying on the shell interface, that CI yaml that passes variables is relying on the the shell interface, etc. It runs just for a few milliseconds, to pass and glue things around, super simple. Powershell is just not designed nor suitable for that.

The problem of an uniform interface _can_ be solved by changing how people write stuff. The problem of not fitting well as an architectural piece replacement is much more difficult to overcome. Powershell fits Windows though, but that's about it.

Powershell passes data not instructions and a lot of those complaints sound like trying to write another language in Powershell. I've shoved json from node through Powershell into the clipboard and back to filter with select-object and out. the situation making you invoke bat at all is what MS ruined and that's not Powershell fault.

It's not me deciding to mix bat and powershell, and it's not niche:

https://github.com/search?q=powershell+language%3ABatchfile&...

There's a need for a fast, nimble glue that powershell can't deliver on its own.

This is what I meant, these are all examples working around the default execution policy. That's microsoft ruining things not powershell as a language. I didn't say it was niche rare or wrong. It's just bad and it's MS's fault.

Technically it's Windows' "here's a string of the commandline, go parse it yourself" (vs. argv array) that's the issue as every program can interpret quoting, escaping etc. differently. All these programs being from MS (powershell, cmd) does make them a little guiltier I guess.

I don't know if I agree with that. I write Bash; I've written some stuff I really shouldn't have written in Bash. Writing elegant Bash is possible, though I agree it is very easy to footgun yourself with it. The problem is that Bash is right at the middle of "I need something quick" vs "I don't want to break out Golang or whatever" and Bash is installed damn nearly everywhere.

A 50-line awk script though? Get outta here with that lol

I don't trust myself so I need my language to not be bug-prone

(and I don't recommend it for others because if we're looking at it realistically, most people who trust themselves shouldn't trust themselves)

> I don't trust myself so I need my language to not be bug-prone

Which language is that?

Do you write unit tests in other languages? Do you write unit tests for your bash scripts?

Yes, if the "script" is big enough. I use BATS for that.

Shellcheck is amazing at preventing bugs!

it just isn't everywhere though. sh, ash zsh, Mac... windows are all different. you think it works everywhere but really its just breaking and nobody is telling you. python is just as everywhere and that's a total mess.

I’ve spent so much time wrestling with and learning all (most) of these pitfalls, and I consider it time well spent. After my first few weeks I started dreaming in bash.

I totally agree. Bash is an absolute nightmare to program in. Just an utter mess of a language, one which I avoid if at all possible. Whereas powershell is an actual sensible language. I love writing it, and honestly I wish it was popular enough in *nix land that I could feasibly use it there too.

Well, there's nushell, which probably integrates better with *nix than pwsh, although it isn't popular either

PowerShell is more verbose than Bash, and has its idiosyncrasies (like sometimes automatically unwrapping 0/1-element arrays into scalars when you least expect it), but it is more productive and more readable. Object-orientation can be nice to produce pipelines.

For example: find potential file duplicates in a folder, recursively, by grouping by file size:

    Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count

No need to remember arcane `file` incantations, no need to parse textual output. You get real objects with properties, and tab completion can see their structure.

Need to parse JSON? No need to involve `jq`, just `Get-Content -Raw whatever.json | ConvertFrom-Json` and do it directly from PowerShell. Need to convert XML into CSV? ConvertFrom-Xml (or Select-Xml) -> do stuff -> ConvertTo-Csv.

Is `Get-ChildItem` too much typing? Use `gci`, or `dir`, or `ls` (by default only on Windows). Is `Where-Object` too much? Try `where` or `?`. And things are case-insensitive.

You can even simplify your `Where-Object` as

    ... | Where-Object Count -gt 1 | ...

Or, of course,

    ... | ? count -gt 1 | ...

...and how do I get a "manual page" for the command "Get-ChildItem" in the console?

Get-help get-childitem

Also remember to check Get-Help Get-Help.

Also, unfortunately, you'll probably want to Update-Help first, because for reasons beyond my comprehension, PowerShell does not ship with detailed help installed by default.

You can use "man <command>" the same as in nix. The man command is an alias for Get-Help and it retrieves the same information.

There's a lot of nix aliases for Powershell commands. Get-ChildItem is also called with ls, mv calls Move-Item, cd calls Set-Location, etc. They made at least some effort to make it more accessible to people coming from *nix or cmd.

I started my career with a X term hosted on a SunOS pizza box, have written thousands of scripts, more than a few in the KLoC count.

Several years ago, I had to write a complex unattended robust data transfer system in PowerShell. (I know, I know, without more info these “requirements” beg many questions, but they are all out of scope for this reply.)

I enjoyed the experience so much I switched all my shells, on MacOS (my DD) and on Linux (my most common work environments) to PWSH.

What I liked most about it was the power of passing objects in pipelines, and being able to extract/manipulate some of the properties of an object in the first filter and still have access to others, along with those of objects created by that first filter, in filters later in the pipeline.

Immensely powerful.

The consistency of commands, of error handling, and of object properties was also very nice.

Eventually, as the nature of work changed I switched all shells back to bash, as the older muscle memory asserted itself. PWSH as a shell made sense when I was working and thinking so much in that space, but when I left it, it was more effortful to think in PWSH than to resume bash.

There are times I miss it. There is nothing else in the shell space that comes close, or at least not close enough to justify the effort of switching.

Do you remember what the common commands for pipelining you used were?

I feel like my PowerShell struggles are really about not knowing 2-5 core, general-purpose pipelining commands well enough to use in any situation.

Get-ChildItem, Select-Object, Where-Object, Sort-Object or anything that is operating on a collection feel very natural. Often times I'm piping Get-ChildItem into sort to find the most recently created file in a directory.

    |? PropertyName -gt 5            # where-object filter numbers
    |? PropertyName -match 'text'    # where-object filter text
    |? {$_.thing ...}                # where-object filter script

    |% PropertyName    # same as select-object -expandproperty propertyname
    |% { $_.thing }    # foreach loop
 
    |sort
    |sort prop1, prop2
    |sort {$_.Name.Substring(0,5) -as [int]}   # sort calculated thing

    |fl *        # format-list , all properties
    |ft -auto    # format-table, autosize table column widths

    |sv q        # set-variable -name q, same as $q = <...>
    |tee -var q  # same but show the results as well as storing in q

Helpful! Thanks!

Not OP but the "-Object" commands are pretty fundamental to creating useful pipelines:

Select-Object - Pick out specific fields from an object, create calculated fields etc.

Where-Object - Drop non-matching objects from the rest of the pipeline.

Group-Object - Cluster objects into groups based on a shared property value.

Sort-Object - Order an array of objects based on a property value.

Get-Content - Read from a file.

ConvertFrom-(CSV/JSON) - Parse a json/csv formatted string into a powershell object.

ConvertTo-(CSV/JSON) - Serialise a powershell object into a csv/json string.

(Parallel)ForEach-Object - Loop over each item in the pipeline, performing one or more actions on it. Usually occurs at the end of the pipeline, or when you need to call an executable that can't handle pipeline input.

One thing I struggled with in the beginning, was not knowing what properties an object might have. You can pipe any object into `Get-Member` and it'll list its available properties and methods.

Many of the "-Object" commands support the use of script blocks if you need to carry out more complex filtering/projection.

Thanks for the detailed write-up! I'll give them a try today.

Others have provided better answers than I could have, as I don’t remember clearly enough.

What I do remember is that until I understood what I was trying to do and why (mostly error handling around edge cases, all specific to the app), I couldn’t really grok the various object management calls, but that once I’d done a few rounds of PoCing and RTFMing, everything fell into place.

a few years ago I had to write a data integrity check for tens-of-thousands of files. Just crawl the dir and compute filename, size, checksum, maybe date, can't remember. I thought "ooh neat, I bet I can use some powershell trick to compute that tuple for each file", and no. Immediately ran into some obscure limitation with their "pipe" - I can't remember the details, it was like impossible to create many-things from a single-thing - and thought "how disappointing. the one time I give it an honest shake to do something entirely conceivable by the creator and it falls flat on its face.".

Nothing in your description sounds difficult to do in powershell. You can certainly output "many-things" from a part of the pipeline that takes "single-things" as input. Crawling files is a single command, then you can do whatever you want with each one in the next part of the pipeline - "map" from file info object to something else (e.g. custom object with filename, size, checksum, etc props) 1-1, multiplex each file into N output objects, buffer file inputs until some heuristic is met then emit outputs, etc.

A lot of years ago, circa Exchange 2010, there was a limitation on pipelines-within-pipelines which had to be worked around. Files already include name, size, dates, so select all of those and add a calculated property of the file hash using Get-FileHash (MD5 and SHA options):

    gci | select *, @{L='Hash'; E={ ($_ | Get-FileHash).Hash }}


    Get-ChildItem | 
      Select-Object -Property FullName, CreationTime, Length, 
                              @{Label='Hash'; Expression={ ($_ | get-filehash).Hash}}

but even then you could do what you want with a traditional loop and no pipeline:

    $results = foreach ($file in get-childitem) {

        # a hashtable of things you want to be
        # in each object ('row') of the output:
        $data = @{
            Name   = $file.Name
            SizeGB = $file.Length / 1GB
            Hash   = ($file | Get-FileHash).Hash
        }

        [pscustomobject]$data
    }

Thanks for taking my belly aching memory and being constructive. I just vividly remembered the sour grapes taste but I guess it was just due to my incompetence. I think what I didn't know was how to do the nested sub command for Hash. Cheers

No expert in either but I've had to use both a fair amount. Powershell fell into a few traps that rendered it awful to use IMO:

* Trying to be a .NET language. I don't know why the one-runtime-many-languages promise of .NET withered on the vine while it flowered in Java-land without the promise even having been made, but it did. If you're writing .NET code, use C#. (And I say that having worked in one of the very few teams doing large scale development in F#.)

* Failing to get the basics of being a shell right. I can't remember the details as I've left it firmly in the past now, but its handling of redirection was just broken, to the extent that things that were trivial in bash were nigh on impossible in powershell. I got the impression its developers ignored the things bash etc. did well in their enthusiasm over building something new and powerful.

* Being fetishistic about stuff like requiring Verb-Object naming for everything. It's certainly subjective and has its defenders, but IMO it renders scripts ugly, is awkward to type and doesn't materially improve discoverability or memorability at all.

PowerShell isn't quite a .NET language, and you can't really write serious .NET software in PowerShell. But if you need to access the power of .NET (or heck, COM) from a script or an interactive shell, PowerShell lets you do that.

That's the point, though. It's a bad .NET language, but the desire to interact with .NET dictated much of its design. Windows didn't need a way to "access the power of .NET". It needed a decent shell, and sadly still lacks one

Edit: And that isn't to say .NET doesn't need a scripting language. It sorely needs that and the various relatively useless variants on "C# scripting" are testament to that. Powershell isn't, and doesn't even attempt to be, a solution to that lack, though.

To be fair, nothing in .NET required Powershell to make the choices it did (case in point: F#, ClojureCLR) for the integration. I wish to learn it but it being so...wordy definitely makes it an unattractive choice. A shell should be terser than F# or C#, not the other way around.

Yeah, "dictated by" is probably the wrong phrasing. A decent shell with those capabilities could probably have been made, but I do think the drive to make something fancy and new based on .NET was a big part of the reason they neglected decades of insights and successful idioms in the shell space, which were sorely needed on Windows.

>decades of history and successful idioms in the shell space

Just because something has persisted for a few decades does not make it good or worthy of being emulated on a platform different from the platform it started out on.

I don't recall saying that it did. My judgement that Windows needed (and still needs) those ideas is based on heavily using both platforms.

I just gave up on Windows. On every step it feels proactively user-hostile, with non-dismissable notifications, removal of UI customizations, constant reminders to change some settings to "recommended" despite my choice, accompanied by overall loss of reliability.

It feels like there is no more vision, desire and engineering excellence left in the teams responsible for it. I know that there are rare exceptions like Microsoft Store that, as an application, has started to work so much better because the person responsible for it cares, and it uses WinGet for updates and distribution, which is great. But these are droplets in the ocean.

At this point, setting up a Linux distro for a desktop yields incomparably better experience given equal amount of effort.

The only thing that makes me worried is that such a dismal state of affairs damages the image of .NET which is night and day compared to most other products made by MSFT in terms of quality and taste, it already needs help - note how much undeserved good will Go and Swift receive, despite former being much worse than everyone thinks once you look into the fine-print and implementation details, and latter having poor non-macOS support story and ecosystem outside of iOS development. And at the same time no matter the degree of improvement that happens to .NET, it is popular to bash it, even if the criticism is completely detached from reality.

(downvotes only demonstrate my point)

The article is about exactly this. Powershell's job was not to be a decent shell, but to make server management work automatable. Unix style shells didn't solve this because windows was not file based, you need all these hooks into these various api to setup a user, or a network connection or a whatever.

Why it's .Net is also covered and its probably not what you expect.

The odd part is that, at its core, Windows still is file-based. Managing it isn't, but anyone who's gone digging around in NT's Object Manager will be familiar with using CreateFile() to get a handle for manipulating things there.

It's, in fact, pretty pervasive when interacting with Windows programmatically, just as it tends to be on Unix-alikes, and the fact that PowerShell doesn't do well to acknowledge that is frustrating. (Worse, Windows is a better Plan 9 of sorts with MIDL and COM everywhere, and PowerShell falls pretty flat here too compared to the experience of, say, slinging a dynamically generated command stream directly at fossilcons.)

Yes, I could break into C# or C++ for this, but that takes the tasks that rely on these operations firmly out of the hands of paraprogrammers.

Eh, I find PowerShell nicer than bash. And having a way to use .NET/COM stuff ad-hoc can be useful in scripts. For example, to talk to Windows Installer with reasonable performance over COM. Or to launch the best browser:

    (New-Object -ComObject InternetExplorer.Application).Visible = $true

As someone who really likes F#, I wonder sometimes if I should just jump ship to ocaml or Haskell. What made you feel like F# wasn’t ultimately worth it?

I don’t like powershell because it’s so surprising in a billion ways from bash. The tab being replaced with right arrow screws me up, and so does not having the normal commands, and it’s quite opinionated about naming.

That said, powershell seems more capable than bash if you know it well, because it has a better type system and arguments are easier to mess with, whereas bash things are amorphous strings.

https://github.com/bionicles/tree_plus/blob/main/tests/more_...

That’s a slightly out of date version of what I use to provision stuff on my windows machine to test things, and can show what’s possible a bit.

I find it is in a weird spot where it is more powerful than bash but you often don't need that power or if you do coding in c# might be better.

It is very good of you want to work with Azure though. You probably don't want to use bash for that. But lots of reading up each time I use it. Bash is my go to for small jobs or a command line experience.

I am not an expert in either but have used both plot to get stuff done.

Most times if I’m doing anything suitably complex it ends up as a little C# app rather than powershell.

I used a Powershell-script in a recent project and learned some lessons. It gets some data from an API. It is run dozens of times every minute, can run concurrently with itself, has some writing to a json file cache in a race condition free way. Works mostly ok. Development has been difficult because of low volume of forums talking about Powershell. Wouldn't have bothered to make the script without ChatGPT. One time it failed by inexplicably setting system+hidden+read only flags in a project folder. Quite a head scratcher. The worst experience was a bug I still don't understand: The script failed to get an access token when running in "ordinary powershell" but managed to do so when running in Powershell ISE. I checked every possible environment difference and concluded that there was only one: powershell.exe vs powershell_ise.exe. I am not going to be making any more Powershell scripts.

Well I used powershell a lot when I was managing VMWare infra. Ultimately the force of a object oriented shell is in the ecosystem, I haven't found any other use case where powershell was useful to me. I am pretty sure it is useful in an Azure context too but in the last few years I have never been in a situation where I would feel the need to install powershell on my linux workstation to use a specific module/use case.

Powershell is a huge improvement over cmd. However; much like Windows, it is full of complicated gotchas and edge cases. Bash has them too, but Bash makes concurrency and parallelization extremely simple, so despite it's absolutely bananas syntax and rules for hash tables and arrays, it is superior IMO. Bash also makes it simple to write your own more complex utilities in any language and call them from bash. Linux makes it simples to implement new kernel tech and Bash makes it simple to interact with the kernel.

Windows... You have to wait until someone in WDG decides some existing idea is good and then also wait for them to get support to implement the idea, then wait to see how that whole thing goes. So yeah Powershell is great for interacting with Windows. But Windows thinks you're a dumb shit so you can only do what Windows already lets you do.

I was extremely well versed in PowerShell early into its development.

It was indispensable when it came out. VBscript and Cygwin were the only options; both of them sucked. The ability to use native .NET objects in scripts was insane; I definitely abused that!

Nowadays, Git Bash and WSL2 replace a lot of the value that PowerShell provided.

It's purpose was to drive Microsoft away from the GUI, and, at that, it more than succeeded.

> VBscript and Cygwin were the only options; both of them sucked.

I'd challenge the Cygwin aspect. With judicious use of cygpath & co., you can go VERY far with Cygwin. I've built an entire SaaS deployment system on top of it (and Python).

A shell is not a thing by itself. It's only as good as it integrates with the rest of the system.

So, the experience of PowerShell on Windows is unbeatable... on Windows. It's easily beaten on any other system.

I use *sh at home, and Powershell at work. Powershell has a lot of really cool and genuinely useful concepts. There's the obvious like piping objects instead of raw bytes, but there's also things like first class parameter validation, automatic array flattening, multi-threading, full .NET API interoperation, and more.

Unfortunately, it also has some real sore points for use as an interactive shell, and even some outright broken behavior. Some that I lament most frequently:

- Powershell has native tab-completion support, but the word-of-god dictated "Verb-Noun" command naming scheme means almost every command shares a common prefix with a slew of entirely unrelated commands, making tab-completion painful.

- Power shell has sparse built-in support for funtional style list manipulation or data structures beyond lists. There's a "map" command (%), but no reduce, zip, tail, etc. These feel like they'd fit in perfectly to the design of the language, but they're just missing. Also, pipes are lazy, but lists are always strict, which can cause friction.

- most operators are strangely named, such as "-eq" for ==, which hurts legibility.

- There're lots of unvoidable brackets, meaning you often need to jump around the line while writing out a command incrementally. For example, to get filenames, you either need to write `(Get-Item).Name` or `Get-Item | %{$_.Name}`. It'd be nice to have something like `Get-Item |. Name` as an option.

- It's impossible to pipe raw bytes between commands/executables; raw bytes are interpreted as strings. This means, for example, it's impossible to pipe a file to `patch`, because the contents will be decoded into strings, piped as strings, then re-encoded with line endings changed, which `patch` rightfully refuses to apply.

- Running Powershell scripts is disabled by default (WTF?)

By comparison, *sh's heavily favor interactive use. For example, you can put io redirections at the start or end of a line, tab-completion is often very good, it's often possible to avoid brackets (ex. with xargs), background/foreground job management, etc.

Overall, I often find Powershell more pleasant to use than *sh, especially when writing scripts. But for interactive use, I often wish Powershell was a little smarter and a little dumber at the same time.

Why is automatic array flattening a good thing? This has caused more bugs than I can count. Every time I make an array I have to check if it has a length of 1 and do something special with it or else the script blows up. Best I can tell this is a huge foot gun anti-feature. What am I missing?

It's a foot gun, and the behavior is often surprising until you get used to it and sometimes after, but Powershell would be very painful to write without it. Basically all functions return a list in Powershell, including all user-defined functions, so you'd need to unwrap singleton lists all over the place.

But if they COULD be lists of >1 then by unwrapping it you have two scenarios to handle instead of one. How is this an improvement? And if it is ALWAYS a list of one why return a list?

All Powershell functions are basically python generator functions. It could have been designed to have more traditional functions, but I find generators fit well into a language based on piping streams of values between functions.

Usually, the distinction between a single item, a flat list, and a list of lists isn't important in Powershell, because commands are written with Powershell's behavior in mind. It's extra painful when it does matter, but it's a trade off against being more verbose every time it doesn't matter. Ultimately, it's personal preference; for an interactive shell, I like the tradeoff Powershell made, and I think it's a cool design space to explore, but I do think there's a lot of room to improve the implentation of the concept to make it less surprising and less painful to choose the alternate behavior when needed.

This works:

    Get-Item | % Name

Welp, I wish I'd learned that earlier.

I switched to menu completion and the tab completion isn’t as painful with all the choices.

I have used it for nontrivial stuff. The idea of streaming objects has a lot of potential, but I think the "enterprise crowd" had a really good crack at it - especially the syntax. Not having to resort to grep, jq, cut, and the host of tools required to (often fragile) parse out whatever specific format the tool you are calling is giving you.

Put another way, you could feel free to parse the output of ls in powershell - because it's already been done for you.

They should have called it PowerScript, because it's a perfectly decent scripting language and an absolutely horrendous interactive shell language.

I'm not an expert, but I use UNIX/Linux at work and only Windows at home (I have a dormant Arch Linux install that I haven't touched in a couple of years), and hopefully you think I'm qualified to respond.

I feel Bash is a 'glue language' in every sense of the word, and is optimised for interactive command-line usage because of its terseness. Being remotely productive on Bash presupposes the presence of an entire UNIX subsystem and coreutils (which is why Git Bash for Windows drags along an entire `/usr/bin` directory with all the coreutils in it). You can't really do much in it without the coreutils.

I find that Bash parseability and ease-of-understanding rapidly deteriorates in scripts of increasing complexity. After about a hundred lines of code I reach for other languages. I personally dislike its unintuitive syntax, global scope, and weak, dynamic typing. The terseness that lends itself to powerful interactive command-line usage means script readability plummets. Of course, that might just mean I'm inexperienced with respect to Bash and need more practice, but I find this a fairly common opinion amongst colleagues and friends. In my opinion, Bash scripts are write-only. It is a wonder that something like neofetch[1]—which is an eleven thousand-line monstrosity—lasted this long (if I recall correctly the author stopped maintaining it because—amongst other reasons—it had just become too complicated).

I find that people understand PowerShell better when they realise it is closer to Python than any interactive UNIX shell. By default, PowerShell is more verbose than Bash; for instance, the PowerShell equivalent of the two-character all-lowercase `ls` is the thirteen-character mixed-case `Get-ChildItem`. Arguments are by default also long and verbose, with things like `-FollowSymlink`. PowerShell is generally meant to be used in executable scripts, just like how most Python isn't executed in the interactive REPL, but by running scripts. Consequently, I find this verbosity lends itself to improved readability in scripts, at the expense of some interactive productivity. That being said, common PowerShell commands have UNIX-like aliases[2] (at one point the cause of much gnashing of teeth here and at /r/programming because PowerShell aliased `curl` to `Invoke-WebRequest`[3]) to improve interactive productivity. PowerShell also supports truncating parameter names; for instance, `Get-ChildItem -Recurse -Force` can be abbreviated to `gci -r -fo`, which looks remarkably like a UNIX command now. Even so, the PowerShell ISE and the PowerShell VS Code extension both suggest that programmers use the full unabbreviated commands and arguments in `.ps1` scripts[4].

PowerShell is also dynamically typed, though semi-static typing can be opted in to[5]. That said there is some controversy about arrays decaying to scalars when they have size 1 [6]. It is easy to set up both function and script parameters with as much power and expressiveness as `argparse` for Python, but natively without involving any additional modules[7].

The real power (pun not entirely unintended) of PowerShell comes when you realise it is just another front-end to the incredibly massive .NET ecosystem. Where Bash requires a full UNIX subsystem and a collection of hundreds of additional binaries to be productive, PowerShell employs pre-compiled cmdlets[8] written in .NET (usually C#) to augment the basic language. Most 'commands' in PowerShell are cmdlets, including `Get-ChildItem`. You can write your own 'back-end' in C#, F#, C++/CLI, VB, or any other .NET language, compile it, and expose a PowerShell interface for end-users. Pretty much like how people write fast but complex code in C/C++, compile it, and expose a Python interface (Numpy, Pandas, PyTorch, etc come to mind). You can additionally directly call .NET methods in PowerShell[9].

This also means that everything in PowerShell is an object. The output of `Get-ChildItem` is a list, not a string. Likewise for `Get-Process` (UNIX equivalent: `top`). These lists may be formatted[10], filtered, parsed, modified, dumped to JSON, and otherwise manipulated like any other list data type in most other languages.

PowerShell also lends itself to the side-effect-free/functional/monadic map-reduce paradigm very well, with pipelines[11].

In my opinion, it is not merely 'better than CMD'; it blows CMD out of the water. A little less so for Bash, because Bash is augmented by the UNIX core-utils. As should now be evident, in my view the real competition to PowerShell is Python.

[1]: https://github.com/dylanaraps/neofetch/blob/master/neofetch

[2]: https://learn.microsoft.com/en-us/powershell/scripting/learn...

[3]: https://news.ycombinator.com/item?id=12319670

[4]: https://learn.microsoft.com/en-gb/powershell/utility-modules...

[5]: https://stackoverflow.com/a/115815/1654223

[5]: https://superuser.com/a/414666/1132163

[7]: https://learn.microsoft.com/en-gb/powershell/module/microsof...

[8]: https://learn.microsoft.com/en-gb/powershell/scripting/power...

[9]: https://devblogs.microsoft.com/scripting/learn-how-to-use-ne...

[10]: https://learn.microsoft.com/en-us/powershell/module/microsof...

[11]: https://learn.microsoft.com/en-gb/powershell/module/microsof...

I just find everything about powershell tricky. Something just doesn't click for me. It's always a struggle.

Exactly my experience.

It took me about a decade to be comfortable with it :)

Reply on news.ycombinator.com