PSKoans: A simple, fun, and interactive way to learn the PowerShell language

https://github.com/vexx32/PSKoans

by thunderbong • 3 years ago

135 53 3 years ago

github.com

motohagiography• 3 years ago

A strange game. The only winning move is to write scripts in powershell.

baal80spam• 3 years ago

Greetings, professor Falken.

rideontime• 3 years ago

Thank you for this, I've avoided learning powershell for as long as possible but recent circumstances have left me no choice in the matter.

waste_monk• 3 years ago

Powershell has plenty of warts and weird design choices, but hopefully once you immerse yourself in it you'll find it's actually fairly nice to work with. The "object pipeline" nature of it means that working with complex structured data is far easier than trying to mangle the same data as lines of text in a traditional shell.

beoberha• 3 years ago

I’m with you. Powershell is a jarring experience for someone not used to it. Heck, it’s still jarring for me and I’ve been working at Microsoft for over 5 years. I truly dislike writing it.

That said, it’s so much more “usable” than any other shell or scripting language. It’s hard to explain to someone who hasn’t used it, but I even reach for Powershell over Python in my daily work.

reassembled• 3 years ago

Just today I used ChatGPT to turn our existing batch scripts into PowerShell, and convert the existing environment variables into command line options. Worked flawlessly and saved a ton of time.

ellipticaldoor• 3 years ago

yes, that is very useful

celadin• 3 years ago

Nice! GPTs have proven invaluable for PS stuff. I have it add comment-based help blocks when I don't feel like writing them myself :) super easy.

mnadkvlb• 3 years ago

Nice :). I would have loved if this existed a few years back (story below).

A few years back when i was consulting, my manager threw me in a meeting for a client wanting to use ping identity to synchronize their identity data for sso. The client wanted a cheap solution as their ping sso budget was overblown already so i tried making a call with powershell to ping sso which worked. We agreed on a day next week to write this client in powershell (which i didnt have much clue about at that time).

Took a book called powershell in a month of lunches and just started doing the lessons in my train rides from my work to home over the week (2hrs in total a day).

The next week when i met the client, we finished writing the sync client in less than a day including testing. The client later told my ex-manager, that it was the cheapest and fastest IT solution they got.

Tl;dr: amazing book to learn powershell: powershell in a month of lunches.

mkl• 3 years ago

Don Jones - Learn Windows PowerShell in a Month of Lunches

toyg• 3 years ago

You messed up there, buddy. You should have charged for all the time you spent reading up on it, not just the day with the customer.

ainar-g• 3 years ago

I'll share a bit of personal experience for those who hate PowerShell to maybe make them look at it from a new point of view.

As a devoted Unix fanatic, I used to hate PowerShell, because I initially came in with the expectation that it's going to be “just another POSIX-like shell”. After all, it's right in the name! And it uses dollar signs! So every little thing that differed from my unixey expectations made me angry. (Them using awful aliases like wget and curl didn't help. Seriously, what were they thinking?)

But once I've realized that PowerShell is much closer to AWK and Perl, I kind of started to almost enjoy it. Don't get me wrong, it's not my favourite language or anything. But these days I think that it is a formidable scripting language with most of the stuff you'd normally need in place, at least in the recent versions.

One thing that I still dislike is the absence of something like the Unix manual pages. For some reason, help pages require additional installation, and the learn.microsoft.com search is so awful that it's often quicker to use DDG with "site:learn.microsoft.com".

mananaysiempre3• 3 years ago

I've realized that PowerShell is much closer to AWK and Perl [than to POSIX shell]

For me, what distinguishes[1,2] the former category from the latter one is that the latter one is quick and comfortable to use interactively, as a shell for the OS, to iterate at the command line and not in the editor, while the former one... isn’t. The cost is that a couple hundred lines of AWK are usually fairly OK, while the same amount of shell visibly strains the language.

Are we still in the world where the interactive text-based environment (not programming environment) with the best available ergonomics is based on a general framework set in 1979? I’m aware Lisp machines existed and did things differently, but the best you can get in that respect now is Emacs and it still cannot reach that seamless ad-hoc composability of Bourne shell.

[1] http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html

[2] https://scsh.net/docu/html/man-Z-H-1.html#node_toc_node_sec_...

throw_a_grenade3• 3 years ago

Are we still in the world where the interactive text-based environment (not programming environment) with the best available ergonomics is based on a general framework set in 1979?

Yes, because it's not broken (certainly not for interactive use), so it's not in a need for fixing. People who don't understand it are doomed to reinvent it poorly (vide curl/wget aliases in powershell).

jodrellblank4• 3 years ago

"Them using awful aliases like wget and curl didn't help. Seriously, what were they thinking?

Seriously they were thinking "if people open our new shell, type a command they expect to work and get an error, they will quit it and never come back. Let's make some aliases for common commands to give people a helping hand so that `cd` and `dir` and `type` and `move` and so on from command prompt, and `echo` and `ls` and `cat` and `md` and `ps` and `mv` and so on from Unix shell, all do something useful. If people have to start right in with PowerShell specific `gci` (get-childitem) and `sl` (set-location) and `mi` (move-item) that will be too unfriendly and too steep learning curve.

It was a great idea; if you're a Linux user you're well aware that the same command can behave differently on different systems (see: grep, egrep, fgrep, POSIX standards vs GNU utilities) and both aware and comfortable with customising your environment with startup scripts (removing aliases if you don't want them). On the other hand if they didn't do that, they were going to get grief from the Windows side (breaking backwards compatibility) and from the Linux side ('all shells must be POSIX'). Damned if they do, damned if they don't. At the time (~2006) PowerShell was Windows only and CURL was not a common Windows tool.

YeGoblynQueenne4• 3 years ago

Besides, it's just faster to write "ls" than "Get-ChildItem". Linux command names come from a time when pressing keys on a keyboard was very expensive [1], so they're very economical. Nowadays we can type keyboard keys as long and as fast as we want and shell command names just get longer and longer.

________________

[1] In the 1960's it cost 10 XP to press one key. 15 for the Return key.

pxc2• 3 years ago

Seriously they were thinking "if people open our new shell, type a command they expect to work and get an error, they will quit it and never come back. Let's make some aliases for common commands to give people a helping hand so that `cd` and `dir` and `type` and `move` and so on from command prompt, and `echo` and `ls` and `cat` and `md` and `ps` and `mv` and so on from Unix shell, all do something useful. If people have to start right in with PowerShell specific `gci` (get-childitem) and `sl` (set-location) and `mi` (move-item) that will be too unfriendly and too steep learning curve.

There are lots of problems with this, not the least of which is that these aliases prevent you from using ports of those actual commands in your PowerShell session, even if you have them installed. And they are absolutely worlds apart from the commands they alias— pretty much totally incompatible. The differences between those PowerShell commands and their GNU equivalents isn't at all in the same ballpark as the differences between GNU coreutils and their counterparts on FreeBSD.

customising your environment with startup scripts (removing aliases if you don't want them)

Doing this in a concise way is annoying as hell. And you can't even do it with a uniform interface, because some of those things are aliases and some of them are built-in functions, and those have to be disabled via different APIs. To avoid totally ruining your shell startup time, you also have to precompute a generated list of external programs to unfuck instead of just piping PowerShell commands to each other in your profile because PowerShell is insanely, insanely slow— especially on a Windows machine where half a dozen grubby little agents want to get their fingers into the filesystem's filters... which is how you're going to be using the damn thing.

I would way rather have a steeper learning curve then have all my muscle memory screwed over with no easy, performant way to toggle the disagreeable behavior. I'm fine typing `gci` instead of `ls` most of the time. When I type `ls`, it's because I want the damn `ls` I went out of my way to install!

At the time (~2006) PowerShell was Windows only and CURL was not a common Windows tool.

Even among developers and sysadmins, Windows users hardly use the CLI. The difference in CLI usage at Microsoft shops vs. everywhere else is might and day. Let the Windows CLI users damn you, all six of them.

And of course there's already a sane solution to this, by the way: a command-not-found handler. All PowerShell has to do is tell you when you run `grep` and it's not present that there's this really neat tool built into PowerShell called 'Select-String'. And if you do have `grep` installed, it can stay out of your damn way.

As an aside: most of these issues have nothing to do with being POSIX. Most of those aliases are for external programs that have nothing to do with the compliance of the shell with POSIX. And lots of times, deliberately non-POSIX shells get them right where PowerShell doesn't.

FTR, I actually like PowerShell. I think it has made a huge contribution to the future of the command line, scripting, and shells in general. I'd much rather write a PowerShell script than a bash script, for anything important and non-interactive. But the things people will say in defense of PowerShell's very bad aspects drive me up a wall.

WorldMaker4• 3 years ago

One thing that I still dislike is the absence of something like the Unix manual pages. For some reason, help pages require additional installation, and the learn.microsoft.com search is so awful that it's often quicker to use DDG with "site:learn.microsoft.com".

I haven't found a case where `Get-Help` hasn't met most of my need for something like Unix `man`. `Get-Help` is even by default "helpfully" aliased to `man` in PowerShell.

It is weird that sometimes you need to `Update-Help` somewhat frequently, especially if you install a lot of modules regularly, but some tools have gotten better at calling it automatically after module installs and I believe the PowerShell 7+ installers have gotten better than before about making sure the built-in modules are all up-to-date at install time and not just uninstalled/missing. It's also not that weird when you look at how complicated man page installation is in most distributions of Unix (even if it feels magic when it works).

Also, the `-Online` argument to `Get-Help` sends your default browser to the relevant learn.microsoft.com documentation page for most commands. That's a very handy shortcut to searching in my experience.

devinprater• 3 years ago

Goodness Powershell is gross. Why would I went to do get-command or some junk. Ah well, I just need to work with it more. Tried the month of lunches book, but it got rather in-depth pretty quickly to me. Maybe ChatGPT can break it down a bit more.

Joker_vD3• 3 years ago

I suspect you find Powershell "gross" only in a sense that "it is not a sh-inspired shell", but that's quite subjective. Now, cmd.exe, that is objectively gross. But Powershell? Unless your first shell experience was bash and it imprinted on you, no, it's not gross.

ketzu• 3 years ago

Why would I went to do get-command or some junk.

One reason might be to make commands consistent and improve discoverability.

Joker_vD3• 3 years ago

A tangent comment: is there some document with guidelines/list for emoji headers to use in commit messages? I mean stuff like "bug" for bug fixes, "upwards black arrow" for upgrading dependencies, "artist palette" for stylistic changes etc — I like it more than those sad +/-/* headers but I'd like to see this custom written out explicitly.

WorldMaker4• 3 years ago

I think a lot of the emoji choices are personal, but there are plenty of customs written out.

One of the most common I see referred to is gitmoji.dev. It's somewhat popular because it also offers a CLI tool to help write commit messages in that style and to setup hooks to do some basic enforcement, if you wish.

adzm• 3 years ago

I only wish it was easier to put c# code within a powershell script. Would be a great mix of two worlds.

auxym• 3 years ago

It's actually pretty easy to "import" a C# class, either from a string or from a separate .cs file, with `Add-Type`, you don't even need to compile it first.

See: https://stackoverflow.com/a/24881346

SeriousM• 3 years ago

There is no fun in a language with little to no help from the "intellisense/autocomplete" and the verb starting the command like "get-item". Ich you're used to autocomplete one will type "item<tab>" to get available commands or just explore the api - not so in pwrsh. I'm a c# dev vor over 20 years and have troubles to like the ps language.

Guillaume86• 3 years ago

I just type "*item" then ctrl+space and I get this: https://imgur.com/a/bmLWHnU

WorldMaker4• 3 years ago

That is a useful tip that ctrl+space/tab completion supports wildcards.

Also, older versions of PowerShell used to include the ISE which offered better auto-completion UI and I found really helpful for learning at times.

Today the suggestion is to install the PowerShell extension in VS Code if you want the best auto-completion support and a lot of features lit up for .ps1 files. (That's the closest to a modern ISE.) https://marketplace.visualstudio.com/items?itemName=ms-vscod...

axus• 3 years ago

Before version 6, PowerShell would default to writing output files as UTF-16LE. Good to know before reading those in to something expecting UTF-8.

replwoacause• 3 years ago

I love PowerShell. I've built CLI apps, desktop GUI apps, web apps, and integrations using it. Now that I can use it on Mac, Windows and Linux it's even more valuable to me. It isn't without a few shortcomings, but I've tried picking up other languages and keep returning to what makes me productive and happy: PowerShell. I've read the criticisms, and experienced some of them firsthand, but considering all that I've been able to do with PowerShell the good far outweighs the bad.

mxuribe2• 3 years ago

I'm curious....are the shortcomings that you encounter the types where elements of your scripts need to differe between Mac, windows, and Linux?

I ask because i really don't like powershell...but am crafting more and more cli apps on linux, and now (sadly) am starting to spend more time across both linux and windows (forced on windows due to work)...so it makese sense to consider a cross-platform shell.

WorldMaker4• 3 years ago

Anecdotally, I haven't noticed too much pain in crafting cross-platform scripts in PowerShell 7+. Most of the platform differences I've seen in PowerShell are at the "module level" (library of "commands/cmdlets") and most commands that are in platform-specific modules generally are pretty obvious that they are platform-specific modules. A lot of modules are cross-platform.

The biggest shift is learning to trust PowerShell commands/cmdlets and operators over platform-specific binaries like awk/sed/grep and so forth. A lot of those tools and manipulation steps can be done with native PowerShell commands/cmdlets/operators, but it's definitely a journey to thinking in PowerShell terms (that the linked repo looks like it can help with) and using/trusting its object-based tools, especially if you are used to the extended Linux shell text manipulation tool chain as "conversion" between the two paradigms isn't always straightforward.

PSKoans: A simple, fun, and interactive way to learn the PowerShell language

Related Stories