Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I started using Linux in 1997. I've been working at Microsoft for a little over 4 years. There are some annoying things about Powershell (verbosity and slow loading of tab completions etc), but in some ways it's vastly superior to bash, as it deals with structured data and not just strings you have to parse, and it has an extremely powerful standard library API (.NET) at your fingertips.

I still love bash and use it as well. But the hate powershell often gets is misguided.



There was a time in Powershell’s life when stdout redirection to a file (>) would write UTF-16, then that changed to UTF-8 with BOM and now it’s UTF-8 no BOM. During those times some PS versions would allow to change this globally, some would not. Even if you could change it globally, the names for the same encodings have changed.

PowerShell 5.1 “UTF8” actually meant “UTF-8 with BOM”

PowerShell 7 “UTF8” meant no BOM.

If you read a file in PowerShell that does not have a BOM it decodes it as ANSI. Yes, ANSI, not Ascii. Which is a hilarious choice because you can’t even write an ANSI file in PowerShell. The closest encoding you can use is “Default” which will use the system default but your systems default might not be ANSI.

PowerShell is a hot mess. Go read the official docs for character encoding[1] if you don’t believe me.

I have CI scripts that have to use .NET calls[2] in PowerShell to write ssh keys to disk because it’s impossible to write utf-8 no BOM (or ascii) with out carriage returns (\r) being inserted before every new line (\n) even when the incoming string didn’t have them.

File encoding is just ONE of the reasons I hate PowerShell and why it’s so obviously clear people who were not qualified to design a shell, designed a shell.

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

[2] https://stackoverflow.com/questions/5596982/using-powershell...


I'm not sure if we should blame the designers of PowerShell (Jeffrey Snover and his team). If you followed the history of their project, it seemed like they had very good ideas, but it was very hard to get buy-in for anything CLI-oriented in Longhorn/Vista-era Microsoft[1]. They've all had experience with Unix shell and their ideas for object based pipes were truly innovative as far as I know.

I can't speak for Jeffrey and his team, but I feel like a lot of their decisions came from trying to get corporate behind the shell and present it as a shell for Windows. They avoided picking political battles outside of their main goals (a modern shell to replace cmd.exe and the object-based pipeline model). What we've got are a set of decisions that aligned with Windows and Microsoft practices of that day and age:

Microsoft is focusing on .Net as their general platform? We'll implement PowerShell on .Net.

Windows's standard for Unicode text files is either UTF-16 LE or having a BOM for any other Unicode transformation? We'll do UTF-16 by default and always add a BOM if you choose UTF-8.

Windows is using CRLF? Well, we'd pipe CRLF-delimtied text by default.

Visual Basic and C# programmers expect functions to have names like "GetChildItem" instead of something like "dir" or "ls"? No problem, we will set the canonical command name to be a long, programming-language-like name and set up aliases that look (but don't behave) like Unix and cmd.exe commands.

The result was not pretty, but I still appreciate the ideas we got from PowerShell. nushell took these ideas and implemented them in a more modern way.

[1] https://corecursive.com/building-powershell-with-jeffrey-sno...


Lots of explanations, but why can't you globally configure reading with no BOM if writing with no BOM is now the default?

It doesn't seem like it could be for backwards compatibility, as now an old script that writes a file with defaults can't later read it with defaults?


I work regularly in PowerShell and this bugged tf out of me. The result of my digging was: .NET libraries emit textual output in <whatever the offending encoding was, UTF-16 LE or something> -- and since PowerShell is implemented in .NET, it necessarily inherited that default.

Things have improved since then now that everything is implemented in .NET (Core), so if you're working with PoSH 7.x, this is no longer a headache. (I just tested in 5.1, and it seems fixed now, as well.)

Of course, by now, I've just developed muscle memory to add '-enc UTF8' to the end of everything that writes text to disk.


> File encoding is just ONE of the reasons I hate PowerShell and why it’s so obviously clear people who were not qualified to design a shell, designed a shell.

I find that unfair towards their creators. They invented a truly innovational shell, whereas everybody else continued the text-based approach. The object-oriented approach is so much simpler when it comes to process results of Get-ChildItem (ls) or Get-Process (ps) when you get objects with properties, instead of just text. Especially when in text-based shells it matters how you call e.g., ps (aux or -efH or whatever).

Now, I find your statement unfair, because in Linux world, you just create a new shell and whoever wants to use it, can.

At Microsoft, a successor to cmd.exe had to be shipped with Microsoft, otherwise it would never have been adopted. Most big companies would never allow a third-party open-source shell on their Windows servers. Therefore, you must navigate a big ocean of politics and powers, guarantee nackwards-compatibility and meet expectations of thousands of companies. This inevitably leads to behaviour like encoding that is frustrating to use. Until you read the docs, which state quite comprehensively what you have to expect - as you discovered yourself.


It's also worth pointing out that those Microsoft docs differentiate between the two major versions of powershell using the names "Windows Powershell" and "Powershell".


I also enjoy how the online manual pages doesn't even try to tell me which version it's about. It's all just powershell https://learn.microsoft.com/en-us/powershell/module/microsof...


The version picker is in the ToC on the upper left.


I think MS has a team dedicated to confusing naming.


The original project name was "Monad", but once it was nearing release, it got into the hands of the notorious naming prodigies in Microsoft marketing. Then it got changed to Microsoft Shell (MSH) and finally to Windows PowerShell. Great times.


It did not get changed.

Windows Powershell is up until 5.1 because it runs ONLY on Windows.

Powershell 6 was named Powershell Core due to being built with .NET Core. It was not fully compatible with 5.1 and lacked some functions based on the WinApi.

PowerShell 7 is still built on .NET Core, but has a much better compatibility with 5.1. They dropped Core because nobody cared and it's shorter and works equally well on all platforms.

So Powershell is the v7 and Windows Powershell is the old 5.1. Nowhere is that confusing.


Also worth noting that PowerShell is completely independent from Windows now. Not only can you install it in almost every other platform, since it's .NET you can embed the runtime in any .NET application. It's incredibly powerful.


> since it's .NET you can embed the runtime in any .NET application

not actually "embedded", more like a bit of shim code that extracts the runtime into some temporary directory that then runs the actual code.


Not sure what you mean? I've hosted powershell in C# code by referencing Microsoft.Powershell.Sdk - it pulls in the dll at compile time and runs on whatever .Net runtime that is installed and matches the project target.


Wait - you might just have helped me to fix my Invoke-WebRequest testing 3rd party api we have to integrate with. Unexpected character encountered while parsing error line 0 position 0 seems like there is a BOM I wasn't expecting to send in my request and receiver definetly was not expecting to receive it.

Edit: yup, just did small cmd line client and all works. Thanks.


UTF8 with bom is a terrible idea. “Why does the name of the first column in my csv file not match?” is a question I answer at least once a month. It’s as if they’re trying to EEE plain text.


Hey let's not pretend like it's better in the world of Linux/Unix/etc. Now that is one hot mess of everything, just as much as Powershell. It's just those have things we're used to, and kinda learned to (mostly) abstract away without the presence of an over-bearing behemoth such as Microsoft which makes such a thing almost impossible.

As a comparison (to most of us semi-knowledgeable windows / powershell users), ask any semi-knowledgeable Linux user about the difference between Ksh/Bash (or that weird one that Ubuntu pushed and aliased to one of the above for extra confusion). Or ask them if any of them remember how tf to use SED or AWK without looking up the docs because those damn things are made by satan in the depths of hell. Or how to use parameters inside shell scripts, and the various incantations they have to slice and dice the params.


Nushell is plenty fast, works with structured data (also has a vi mode if you care, I do) and works equally well on Windows and Linux. You can install it with winget on windows and with cargo or the system's package manager on linux.

https://www.nushell.sh/


I am a C# developer so I should feel right at home with Powershell. In some ways I am. I do manage to get things done if I have to use it. If I am inside the Windows environment (with other Windows devs) I will try to encourage using it over CMD.

One thing I will give Powershell credit for is, back in 2012, being able to chuck something together when I did not have the development tools I needed. I knew that Powershell was .NET under the hood so I had a stab at being able to load my DLL files and calling methods inside a class. It did the trick! I was able to hand it over, suggesting they use it as a Task Scheduler (daily) and hardly anyone touched it during the remaining of that promotion (4 months)

Despite all this, if I ever have to write a script for odd execution or regular automation... I wish I could use bash. I have mentioned Git For Windows or using WSL but I just cannot win anyone over. Its not like anyone is an expert on shell scripting.. powershell or whatever.

As much as I like Powershell -- I still consider bash to be better. I think half of this reason boils down to what you are accustomed to. I have been using Linux properly since.. around.. 2006.


I am a C# developer and I know it's basically .Net as shell, but I have no clue what to do when in PowerShell. I'm always lost, and without searching the internet I get to nothing. In Bash/Zsh I quickly reach my goals.

I just think coming from a Linux background, it's very hard to wrap my mind around the mindset of PowerShell which is just quite different from Bash.


I just think if I had to write a quick "script" - I would stick to CMD or Powershell in Windows.

If you had to write something a little more complicated, I would consider F# in many ways than Powershell especially if I wanted the .NET tools.

Of course, there is python.


I've used powershell a bit, particularly for scripting CI pipeline steps. No matter how much I use it, I can never remember anything about the syntax. I primarily use C#, so you'd think there'd be some affinity, but nope. It's like a black hole.

I've written in a lot of different languages in my time and never had this issue with anything else. It's weird.


To be fair, I have a similar problem with bash. There is no way to remember how to write a for loop for me


Yeah bash has some of the worst syntax of any language I've used. Why do if statements have a semicolon in the middle of them?? Why does it use `[[` and `]]`? why does `if` end with `fi ` but `while` ends with `done` ?

people who rip on powershell but prefer bash make no sense to me at all


> people who rip on powershell but prefer bash make no sense to me at all

They're used to it, that's all. Just like how people used to US Customary find SI units weird and confusing.


Exact same here. I write roughly the same amount of Powershell as I do Bash, and yet to this day I feel like I barely know Powershell and constantly look up the simplest things, whereas loads of dark corners in Bash stick in my mind perfectly fine.


AIUI the verbosity is by design to make scripts more clear, and users are expected to use aliases to make cmdlets easier to work with interactively. But I assume that few of those aliases are actually standardized...


Virtually all of the built in commandlets have one or more aliases set by default.

e.g. Get-ChildItem is aliased to "gci", "ls", and probably "dir" as well.


Powershell introducing the English language to a shell at a time when everyone else was doing i18n is about 3 leaps beyond an annoying thing in the traditional Microsoft form of the time.

You can do what ever you want for innovation but if you choose mindf*ck as your UI..


Can Powershell tee a background task yet?


I may be misunderstanding, but you can write to the console host in a background task. To get an output stream, you need to await the task and collect the result.


I feel it's nice to have the power of choice, I can deal with structured data in bash as much as I need, whenever I need, with awk, but it isn't there when I don't


Bash rocks because it is about the user and the OS. Powershell is about one thing, Microsoft and the ugliness of ItS CumBerSomE-SynTaX Du-Jour is proof.


Bash is about the user? Are you serious?

It's about what twenty people could sling together and make work on a Vax in the 80s in 4Kb.

Powershell has regular syntax, legibility, a high degree of discoverability, and included batteries for things that bash victims reimplement again and again.

It may not be the best shell for your purposes - it certainly won't run in 4Kb - but it wipes the floor with all legacy shells for usability.

You're welcome to have an aesthetic opinion on the syntax, but you must be dead inside if you can look at an average bash script and not recoil in horror. Argument parsing? sed? Control statements? Quoting and escaping?

"It's all about the user" is it fuck, you're on drugs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: