Hacker News new | ask | show | jobs
by bszupnick 1970 days ago
I think the reason I've been avoiding Powershell is specifically the pattern of `Verb-Noun -Option argument` the author brings up.

I'm not saying it's not "better" (however you measure that) but I think it's very wordy and that's always been a turn-off and barrier of entry for me.

some examples:

pwd --> Set-Location

ls --> Get-ChildItem

cp --> Copy-Item

I totally understand how bash's sometimes seemingly random shortcuts or acronyms can ALSO be a huge barrier of entry (just as it was for me!) and the straightforwardness of Powershell is a lot clearer, but personally now that I'm "in" on the short-hand of bash, it's been hard to start using Powershell.

13 comments

The single most underused command in powershell is: Get-Alias

Essentially every command you'd use has a 2 or 3 character alias that is easy to remember and quick to type.

On top of it their almost programitacilly named, so if you know the powershell commands full name you can almost certainly guess the alias

Typing Get-Alias lists them all out.

https://docs.microsoft.com/en-us/powershell/module/microsoft...

I now have a burning temptation to write "Get-Alias Get-Alias"

  PS C:\Users\Kuinox> Get-Alias -D Get-Alias

  CommandType     Name                                               Version    Source

  -----------     ----                                               -------    ------

  Alias           gal -> Get-Alias
and I have been told by at least twenty people never to use aliases in powershell scripts so aliases are effectively useless.
I think the idea is that in scripts you should use the full name for maximum clarity and self-documentation; in your own terminal invocations, be as terse as you want.
That is precisely the idea. The verbose names are self-documenting. You need documentation (names, types, comments, etc.) when code will be reused and read and altered at a later time.

Interactive use is different. It is write (and tweak) then use once. You never write comments in the interactive terminal. For interactive use you have aliases, plenty of them.

One reason for that is that other people may have different aliases set up, so you cannot count on your aliases working everywhere. Yes, that also means the default aliases, which may (although very rarely) change from version to version.

For PowerShell ISE there was an extension that automatically expanded all aliases, I believe for the current language server there may be similar things. If all else fails, a PowerShell script can do that as well, since PowerShell exposes its own parser in its API, so a script can easily introspect itself or another script.

If you're working on a shared project where people might care, I usually have the [PSScriptAnalyzer][1] just auto-correct any aliases dynamically for me in my IDE.

If you're just doing a quick one-off or interactively, then who cares! Crack on with your incomprehensible one-liners!

[1]: https://github.com/PowerShell/PSScriptAnalyzer

Powershell gives the best of both worlds: readable command names in scripts, and simple Bash-like shortcuts when you type stuff in the terminal.
Is this really the "best of both worlds" or does this just double the number of commands you have the learn?
Since you don't have to learn the aliases, you can use the full command names in the interactive shell, it doesn't double anything.
Last I heard (and I haven't had direct visibility into this since about 7 years ago) aliases are preserved between versions for backwards compatibility, but you shouldn't use abbreviated parameter names in scripts because there's no guarantee that they won't become ambiguous if more parameters are added to a command.
That is true; but since the aliases and parameter names are discoverable with introspection, if you are writing a script you can have a tool which expands them all to their full name if you want that.

That said, the PowerShell team do care about breaking backwards compatibility, so this risk is more likely in a 3rd party module than in the PS main cmdlets.

Then you just end up with bash commands again, such as "pwd" and "cat"
Yes, you do. With the advantage of the rich object model. Best of both worlds.
And you can still use the full names in scripts (rather than directly in the shell), so you don’t rely on future readers knowing the aliases.
Thanks so much for sharing this!!
Aliases don't have short forms for their arguments, so for any serious command you'd still be typing (tabbing) a lot.
Yes they do. Powershell is smart enough to find the argument as long as it's not ambiguous. For instance:

    Remove-Item -r -fo ./path/to/some/directory
Powershell is smart enough to know that -r means -Recurse and -fo means -Force because the Remove-Item cmdlet has no other parameter that starts with -r. For -f there are two possible arguments: -Filter and -Force which is why you need to be more specific with -fo.
oh god, fuzzy matching
No it's not fuzzy. It's long-enough-prefix-string-to-be-unambiguous.
But possibly not forward compatible for future parameter addition?
For deletion!
You can shorten any argument name in PowerShell, so long as it can be disambiguated:

    PS C:\> ls -di # same as Get-ChildItem -Directory; -d would pass the -Depth parameter instead
    

        Directory: C:\


    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    d-----       2020-07-24     18:09                PerfLogs
    d-r---       2020-12-14     22:45                Program Files
    d-r---       2020-12-24     22:57                Program Files (x86)
    d-----       2020-07-23     11:29                temp
    d-r---       2020-07-24     14:19                Users
    d-----       2021-01-15     21:33                Windows

  > ls -di # same as Get-ChildItem -Directory; -d would pass the -Depth parameter instead
Ouch, that is actually worse than I thought. So not only can you abbreviate parameters, but when the abbreviation is ambiguous Powershell just arbitrarily picks one instead of giving an error?
Alias are nice, but if the short version is not enabled by default, it is mostly useless outside of your normal workstation. During the course of my day I'll be working in many different containers and VMs. All of them 'cattle' so they will only live hours to weeks at most. It just isn't worth creating aliases if I can't use them most of the time.

A long time ago I spent time making alias and using custom shells but over time I just slowly reverted to default bash because it is always there and always works the same.

The aliases he’s talking about are all set by default. Most of them IIRC are just simple abbreviations- for example Get-ChildItem is gci.
I didn't realize the alias were pre-defined and not just user created. Thanks for clearing that up in reasonable way.
What the heck is going on with people on this site (or the internet in general) speaking with absolutely complete confidence in something while also being completely factually wrong?

It used to be that some minor point might be wrong; now it's the entire comment! Premise, conclusion, everything!

Have we gotten this lazy and this overconfident that we think sounding confident is enough? That if we thought it up, it must be true? In a technical discussion? REALLY?!

...I don't want to live on this plane of existence anymore.

Please don't post unsubstantive comments to HN. If another comment is wrong, the thing to do is respond respectfully with correct information. Then everybody can learn something. Please don't respond by fulminating about the community. HN is an internet forum and the internet is replete with people speaking confidently about things they don't know about I'm not saying that was true of the GP but it's certainly true in general—and frankly that's just human nature.

The internet, including HN, is also a frustrating and activating place which triggers all sorts of untrue overgeneralizations after encountering things one dislikes: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

https://news.ycombinator.com/newsguidelines.html

(Please see https://news.ycombinator.com/item?id=25862346 downthread also.)

The parent comment may be incorrect (I don’t actually know, more on this in a sec), but your comment is not constructive.

https://news.ycombinator.com/newsguidelines.html

Unfortunately, while accusing the parent of being completely wrong, you have not elaborated on how/why.

Would you explain the issue(s) for the parent commenter’s future reference and for those of us who don’t have a deep knowledge of PowerShell?

The comment you refer to seems like it was posted by a machine, or at least a troll. Note it is very generic and could be inserted into ANY discussion-thread. And cleverly it claims to criticize "over confidence" when in fact it itself tries to get its point across by being forcefully confident about its own righteousness. That is an old rhetorical trick accusing others of something you are doing to take the focus away from your own issues. Reminds me of some politicians
Please don't post unsubstantive comments, call names, or take HN threads further into flamewar. All that is against the site guidelines: https://news.ycombinator.com/newsguidelines.html.
I'm not a troll, or a machine, thank you very much.

At this point I can't edit the comment in question, but every assumption in the comment it was a reply to was wrong. Every single one.

Aliases in powershell are not turned off by default. Aliases either exist or they don't. When speaking of aliases alone, bash is no simpler nor more complex than powershell.

By the way, this comment (the one I am writing right now) is ALSO replying to a comment written by someone who appears to be overconfident and under-informed. It's a freaking malady, and people are somehow proud of their incorrect blind guesswork.

Incorrect, blind guesswork gets a pass, because the statements made sound correct to a layman, and sound objections don't get a pass. I understand, now. I wasn't clear on how important facts are in a technical discussion.

I stated no facts in my earlier comment, that's true, but neither did the person I was replying to. I thought my point was clear. It was less clear than the comment based on false assumption, I guess.

I fucking give up. You assholes can have this.

How is my comment wrong? I said `if the short version is not enabled by default..` which suggests that I do not think they are but am not 100% sure. Ok, I was wrong and rest of my critic doesn't apply but how is this suddenly translate to `I don't want to live on this plane of existence anymore.`? I was just wrong in assuming that aliases were user defined like on most shells.
Wordiness for some interesting reason makes it HARDER for me to remember stuff.

Kind of like I struggled with PMP exam and memorization because "Integrated Change Control Management" became "Controlled Management Change Integration" or "Managed Variation Integration" or whatever in my mind,

"Retrieve-Child-Item" vs "Get-ChildItem" or "Send-Command" vs "Invoke-Command" "Remove-Tiingamajiggy" vs "Delete-Whatchamacallit"... my mind is seemingly better equipped to memorize "obscure but unique" gobbledygook rather than "meaningful-but-generic" verbiage :|

Perhaps PowerShell is the new COBOL?
The rigid and obscure syntactic structure also checks. It's a couple of hours task for me to define a function, mostly spent on debugging the definition.

(Probably, if I did it all the time, I'd get it right every time. Just like creating and using COBOL variables.)

I have the same problem with bash. I have spent hours trying to write a simple function which in PS would have been 10 minutes.
You mean writing the function body? I was not talking about the function body, but about getting the declaration correct. (The bad error messages and lack of real time verification surely contribute here.)

PS is more powerful than Bash, it really should be faster to write a function body in it.

Hah, I was thinking of that... I did have to code in COBOL for 6 months in ~2000 and I see some similarities in syntax paradigm (though superficial of course) - but I figured the reference would be too obscure for majority of HN audience :->
Indeed, I have the same reaction to Powershell syntax as I do Enterprise Java and C# --- extremely verbose and hard to actually read beyond the surface --- the fact that it contains English words is in some ways deceptive. The mixed case Reminds Me Of People Who Always Write Like This, and that's as annoying as it looks. My theory of why it is harder to read is because longer sequences of characters are harder to memorise than shorter ones.
I had the same experience, though eventually just having more practice with powershell it ends up second nature. Especially with the ides and completion that can come with it.
It also doesn't help that by default (at least in my experience), Powershell's tab completion is slow and annoying to use. I don't know if it's technically inferior, but it feels terrible.

It does the thing where you get to cycle through various options instead of completing to the longest common prefix, which is really hard to get used to after years and years of interfaces that do the other thing.

It's also difficult to form a repertoire of common shortcuts over time because so many commands share a prefix, so most often the shortest you will be typing is 5-6 characters before you get to anything unique.

> "It does the thing where you get to cycle through various options instead of completing to the longest common prefix, which is really hard to get used to after years and years of interfaces that do the other thing."

So change it:

    Set-PSReadLineKeyHandler -Chord Tab -Function Complete
"Bash style completion (optional in Cmd mode, default in Emacs mode)" - https://docs.microsoft.com/en-us/powershell/module/psreadlin...
The defaults come out of old CMD.EXE (bad) habits, so so yes are missing like a dozen years of Linux terminal UX experimentation/improvements.

One particularly common advice with Powershell is to try PSReadLine for more bash-like versions of tab completion and other line editing things: https://github.com/PowerShell/PSReadLine

As for common shortcuts, as mentioned elsewhere in this thread, Get-Alias (and Set-Alias) is a very useful tool.

  PS C:\Users\Kuinox> pwd

  Path
  ----
  C:\Users\Kuinox

  PS C:\Users\Kuinox> ls


      Directory: C:\Users\Kuinox


  Mode                LastWriteTime         Length Name
  ----                -------------         ------ ----
  d-----       2020-11-30     15:39                .android
  [private info redacted]

  PS C:\Users\Kuinox> Get-Alias cp

  CommandType     Name                                        Version    Source
  -----------     ----                                               -------    ------
  Alias           cp -> Copy-Item
Every command you listed are default alias in ps.
> "Every command you listed are default alias in ps."

No, ls and cp are not aliases on Linux; the aliases which clashed too much with existing Linux commands were removed in PowerShell core, they only still exist on Windows.

    PS /> get-command ls,cp

    CommandType     Name    Source
    -----------     ----    ------
    Application     ls      /bin/ls
    Application     cp      /bin/cp
I that actual backslashes I spy in there?

Jeezus.

It's on Windows, so yes, path are displayed with backslashes.
Though I definitely agree that bash's abbreviations are a barrier to entry, I think a bigger impediment not just with bash but many languages (say, Haskell) is ungooglable operator syntax.

If you didn't know what it was, how would you figure out what `$(expression)` means in bash for example?

Haskell has https://hoogle.haskell.org/ which lets you search functions named by symbols, function signatures, etc.
Yea, in that case I just search “bash operators” and hope to find a page that includes an example of the one I’m trying to understand.
I think this one is called a "type of quote", not "operator".

At least Bash has a very complete man-page, you can just search for `$(` there and you'll find it. But the Bash symbols all have different functions, there are (very few) operators, quotes, variables, and probably more than I can remember.

bash syntax is terse enough that it's practical at the interactive command line. Thus once you take it up, you take it up for scripts AND daily interactive use. For system operators who use both frequently, between these two you quickly internalize the abbreviations. I can see it being an issue for infrequent users.

While it's not terrible, I find powershell pretty frustrating. I started off enthusiastic, especially given how archaic cmd.exe is. As mentioned elsewhere though, the advice not to use aliases, coupled with unbelievably long command names that I hate typing and can't always recall exactly - is it convert-to-csv? to-csv? no it's convertto-csv - I can never remember and I don't feel I should need to use ISE to work around this. This utterly prevents me from internalizing.

Even worse, until v3 apparently, iterating over an empty array would fail out (iterate once on $null instead of not iterating at all) and had to be protected with an explicit check. I was on v2, and it was at this point that I completely checked out and decided it wasn't worth learning and that I'd wasted my time. In general I could do what I needed with either cygwin or win32 cpython and those didn't make me feel like clawing my own eyes out.

It seems the situation has improved, but I just don't see any reason to take it up again, ESPECIALLY on linux, unless I _have to_ do dotnet stuff, and even if I do I'll explore every other available option first (ironpython? f#? is there a dotnet tcl?) TBH I avoid dotnet anyways given Microsoft's past (EEE) and current (telemetry, start menu ads, etc) behavior. Fool me once etc etc etc.

Commonly used terms/functions tend to become shorter and symbolized as some notation, similar to how all the Math notation came to be. A mathematician would be unproductive without those shorthand notations.

But I guess there is a balance. Not everyone want to write matrix multiplications as A+.×B, though A%*%B seems acceptable to some, most nowadays write it as np.dot(A,B).

Fwiw, those aliases you mention all exist. I always do "ls" and "cd" for example. But what really annoys me is that there's no aliases for arguments. So "find . -name foo" becomes "ls -Recurse -Include foo" which makes my carpal tunnel just a little worse.

It's a shame because the rest of Powershell is so good.

There are aliases for parameters, `-ea` for `-ErrorAction` comes to mind. But those are defined by cmdlets, not the user.

However, you can always shorten parameter names as long as they remain unambiguous with other parameters, so

    Get-ChildItem -Recurse -Include foo
would become

    ls -r -i foo
which just happens to be shorter than your 'find' example.
there's no aliases for arguments

There are (if implemented by the function), and moreover you can use just shrink the name to the point it becomes ambiguous. Your example is the same a "ls -r -i foo".

Also tab completion. You never type those out in full, no carpal tunnel, it's just "l -r" the TAB and select what you want. Discoverability is everything in PS.

Powershell is smart enough to find the argument as long as it's not ambiguous. For instance:

    Remove-Item -r -fo ./path/to/some/directory
Powershell is smart enough to know that -r means -Recurse and -fo means -Force because the Remove-Item cmdlet has no other parameter that starts with -r. For -f there are two possible arguments: -Filter and -Force which is why you need to be more specific with -fo.
For commands you use frequently you can still use shortforms, positional arguments, and tab completion, though.

For instance in powershell you can also do:

    ls -r foo
More importantly, when you have to adhere to the "Generic Verb-Generic Noun" pattern, the namespace fills up quickly and now creating a new program and sharing it is stifled by two problems:

1. coming up with a name that won't clash with others in already-extremely-limited namespace

2. marketing of a generically-named thing.

In the Unix world, let's take top. After top came htop. How would that play out in the Powershell world? List-Processes -> SuperDuperList-Processes?

> "when you have to adhere to the "Generic Verb-Generic Noun" pattern"

a) it's GenericVerb-SpecificNoun usually with a name at the front of the noun like Get-YakubinComments, and you don't /have/ to adhere to it.

b) there isn't a single namespace, you can use the full name style Microsoft.PowerShell.Core\Get-Command if you want to disambiguate namespaces.

c) You can `import-module -prefix ZZ` and then all commands in that module will get your prefix at the start of the noun part, like Get-ZZYakubinComment to avoid clashes.

> "How would that play out in the Powershell world? List-Processes -> SuperDuperList-Processes?"

No because List- isn't a standard verb, nor is SuperDuperList. Get-EventLog had Get-WinEvent added. Get-WmiInstance became Get-CimInstance. The third party NTFSSecurity module added a Get-Item2 to cover for Get-Item, and a Get-NTFSAccess to cover for Get-ACL.

And because it's a shell and can run binaries, there's no problem with you having or running top and htop. or aliasing htop or calling your own thing htop, the Verb-Noun pattern isn't mandatory, it's recommended for companies developing modules so that administrators will have ideas how to list things, add things, remove things, without having to read the manual to find that it's mysterymgmtcli --auth-control -login-create instead of New-ToolUser.

Namespaces in a shell gives me all the bad vibes of XML namespaces.
Microsoft may contribute to open source but not all contributions are good. Powershell breaks with every significant open-source language style and is therefore a typically bad investment of time for a non-Windows developer.

MS technologies have sometimes been a bad investment for Windows developers too.

That is ridiculous. Please don't spread FUD.
I'm not sure if this is relevant but I tried all three of the Linux commands in Powershell and they worked as well.
All of those are aliased to the Linux commands and also have their own abbreviations (get-childitem -> gci).
As others have said, aliases do exist, but I don't think you can deny that verb-noun makes learning Powershell a lot easier. For instance, if I want to get a user account, you know that Get-User exists. You can therefore also assume that Set-User also exists as a command. Tab completion helps a lot too with figuring out what options there are.
That's what aliases are for. All three examples are there by default for me as aliases.