[AdmiralAsshat]

Article might be more successful if it demonstrated some of the advantages of PowerShell, such as returning the output as objects instead of lines, and what you can do with them as a result.

I'll admit to being in the "Bash is what I know, I'll just install WSL/Cygwin/PuTTY on my Windows workstation and be done with it" crowd. PowerShell is on my bucket list of things I need to learn at some point, or at the very least just get a RosettaCode cheatsheet of common stuff I do in bash and how to do it in PowerShell for when I'm stuck on remote Windows servers.

[AnthonyMouse]

> Article might be more successful if it demonstrated some of the advantages of PowerShell, such as returning the output as objects instead of lines, and what you can do with them as a result.

The costs of doing this don't get enough mention though. You're essentially locking yourself into an ecosystem.

It's typical in bash to have a pipeline where every program is written in a different language -- shell scripts, Python, C, C++, Rust etc. They can all operate on text, but what is a Python program supposed to do with a Rust object or vice versa?

It only works between two programs that support the same object format. But in that case you're effectively passing an object to a function in the same language. Languages already have that with lower overhead than pipes. Even if you're set on using pipes, nothing really stops you from piping a binary format object from one program to another, as long as they use the same object format.

So I think the people who say to compare PS to python and not bash are right, but it's not even that -- just compare it to any other language that has objects. It can pass the objects easily within the language but not outside of it. That's hardly a novelty. And then, despite the ostensible ports to other platforms, you have the usual drawbacks of vendor-specific languages -- many of the APIs only exist or do something useful on Windows and you're locking yourself into the platform.

[AdmiralAsshat]

Sure, but my understanding is that PowerShell by itself can do alot of the stuff I typically use four or five pipes to accomplish (e.g. `grep regex myFile | sort -u | cut -d ',' -f 3`). In which case, it might not be as much of a problem for most use-cases.

[AnthonyMouse]

Sure it can, but so can one python script. For that matter, so can the four or five pipes. What's so wrong with `grep regex myFile | sort -u | cut -d ',' -f 3` etc.?

[thesuperbigfrog]

It would be nice if PowerShell had object serialization and deserialization functions built into the language or standard library, similar to the Common Lisp read and print functions.

This would make it possible for PowerShell to interoperate with other command line facilities.

[JamesSwift]

Does `ConvertTo-Json` and `ConvertFrom-Json` not handle what you want?

[thesuperbigfrog]

Awesome. Thank you for letting me know about those. I have been using bash and Perl for many years, but have only dabbled in PowerShell since almost all of my work happens on Linux.

I am bookmarking those because I expect to have to use PowerShell for some automation tasks on Windows in the near future.

[chipsa]

PWSH runs on top of the .NET runtime. So you can use any CLI language to write your code: C++, C#, VB, F#, Python, as well as PWSH.

[AnthonyMouse]

So you're locking yourself into an ecosystem. You have to replace everything with .NET.

Even existing things that are written in C++ or Python would have to be specifically rewritten to input and output .NET runtime objects. And why use that rather than any other object format that isn't tied to a specific vendor?

[rasengan]

I made a Bash script for HN, and while I’m the furthest thing from an expert in Bash (I’m a newb), I was impressed by a contribution made with a port of the script to Powershell[1]. You can see the same script compared in Bash, Powershell and Python!

Prior to this I had never really explored PS, but it is definitely cool

Shameless Plug:

[1] https://github.com/realrasengan/autobahn

[gabrielsroka]

Thanks rasengan. I've been using PowerShell for about 5 years now. I was trying to learn Bash, but I found too limiting -- it was like going backwards. So, I started learning Python.

You'll notice that the PowerShell and Python versions are very similar.

[theamk]

Yes, because they do much less than the shell version Here is a shell version which does the same thing as python, it is much smaller as well:

https://github.com/realrasengan/autobahn/pull/8/files#diff-6...

[gabrielsroka]

In fairness, when I ported the Bash version to PowerShell and then Python, the Bash version was much shorter. rasengan later added a lot of functionality to the Bash version.

And the point was to demonstrate some of the functionality in a short example, not to be a line-by-line port. I find it's easier to learn a new language by looking at a short example. The rest is left as an exercise to the reader.

[rasengan]

Thank you gabrielsroka!

[theamk]

This seems pretty unfair to bash - bash version is way longer than needed, both because it does more (more fields, difference tracking) and because it is written very vebosely (very long prefixes on each var, using multiple calls instead of single “read” command)

I really dislike those comparisons where one side wins not because the language is better, but because it does much less.

[rasengan]

I agree, and I see that you posted a better comparison with hn.sh! Thank you so much theamk!

[GordonS]

Thanks for posting this, it's interesting to see the same problem solved in 3 languages.

I use Bash for all my scripting needs, on both Windows and Linux - I just can't get over my dislike of Powershell's verbose syntax and Pascal-Snake-Case naming!

But some things are difficult or finicky in Bash; maybe I should stop putting off learning Python...

[gabrielsroka]

PowerShell commands are not case sensitive.

Commands use <Verb>-<Adjective><Noun> structure, for example Get-ADUser gets an AD user. Once you learn that, it's easy to know that the equivalent command for AzureAD is Get-AzureADUser.

It did take me a while to get used to it, but it does make sense, and it makes it easier to learn/remember commands.

[GordonS]

I know about the lack of case sensitivity, but in idiomatic Powershell, it's Pascal-Kebab-Case. If I use a language, almost everyone else's code is going to be idiomatic, so I would write idiomatic code too.

[majkinetor]

Thats silly. You can equally complain about short vs long parameter names with most CLI tools (- vs --).

You also have tools for that just write short and use Expand-Alias

[GordonS]

Well... yes, I suppose it is a bit silly! I've really tried to like it, but I just can't get past it.

It's just my personal preference, but I've come across quite a few others who dislike the naming of Powershell commands too - seems to be a real love/hate kind of thing.

[JdeBP]

A very basic example of that, from my own use, is storing the result of a frequently issued large recursive directory search that always returns much the same list of files in a variable, and then using foreach to iterate over the variable multiple times to do stuff. Being a list of objects rather than an array of strings means that object properties and methods are still available within the loop bodies, the objects not having been flattened into just filenames.

PowerShell occupies the same area on Windows that REXX did on OS/2, indeed the same area that Object REXX did. Its useful properties are not that it can be made to look somewhat like POSIX shell commands. In many ways asking "What are the advantages over a POSIX shell?" is not even asking the right question. Its useful properties are rather different.

One such is that it can be used as an interpreted environment for rapidly prototyping .NET programs. I've used it to interactively do quick and dirty mixed file and SQL handling that would have required several full edit+compile+debug cycles in C# (and not just edit-and-continue).

It can speak to anything that has a .NET API. This includes Windows Forms. https://github.com/jdebp/terminal-tests/blob/master/PowerShe... is a PowerShell program that uses ECMA-48 output to Windows Terminal to draw a wriggling worm, with a Windows Forms dialogue box alongside it that can control various test parameters as it goes.

It's employable in the same sort of "glue" areas that REXX was. It is very useful in Azure/TFS build pipelines, for example. Don't think of it as a "server" thing because of this, though. It's a "glue" thing, as useful on desktop machines as on servers. It's the same improvement over writing glue as CMD scripts on Windows as REXX was over writing glue as CMD scripts on OS/2.

I haven't explored its embeddability myself, but like TCL, REXX, and others it can be used as an embedded in-process scripting language within other programs. Again, this isn't something that one directly contrasts with a POSIX shell.

[JamesSwift]

I absolutely abuse Bash for more usecases than I should on my mac, but you owe it to yourself to try out Powershell Core on PC. It is very, very productive. If it weren't for a couple nuances, I would consider switching to it on my Mac as well.

[badloginagain]

PowerShell takes some time to grok, but once you get it it has very deep integration with Windows systems, and can become a joy to work with.

That being said, I still feel violated every time `ls` returns `bad command or filename`

[ooboe]

Are there different versions of PowerShell? 'ls' has always worked for me. 'ls -al' does not however, and that does feel a bit violating.

[JamesSwift]

`ls` is an alias on windows systems. I dont remember what the command maps to, but it maps to something. Same thing with a lot of others (e.g. cat is an alias for Get-Content)

[ksaj]

You could always make aliases. For example, ls would be 'wsl ls' to run the ls command from Linux instead of searching down the Windows exec path for it.

Also, I noticed at least my version of powershell actually has a built in 'ls'. It isn't quite the same as 'wsl ls' but it does show results more appropriate for Windows file systems.