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...
PS C:\Users\Kuinox> Get-Alias -D Get-Alias
CommandType Name Version Source
----------- ---- ------- ------
Alias gal -> Get-AliasInteractive 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.
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 just doing a quick one-off or interactively, then who cares! Crack on with your incomprehensible one-liners!
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.
Remove-Item -r -fo ./path/to/some/directory
People don't want that, but the PowerShell Team are not moving easily to a possible-break of backwards compatibility in how the language parses variable names. It's been discussed here: https://github.com/PowerShell/PowerShell/issues/3240 for dozens of comments, and goes:
"@PowerShell/powershell-committee reviewed this one today, we have a couple thoughts: No matter what we do, we're going to do some analysis of our corpus of scripts to see how often folks use ? in variable names. Some of us have a hypothesis (that others would like to validate) that the users who are using ? in their variable names may be less advanced users (as we agree in this room we'd stay away from it because of the potential problems that could arise). On the other hand, anyone using the functionality described here will be able to understand a slightly more complicated syntax (like ${foo}?.bar). Therefore, we prefer option 3 because it avoids breaking changes on these less experienced users."
The committee ruled to keep the need for ${}, then the ternary expression became a gated experimental feature in PowerShell 7, you have to opt-in to enable it. One of the PowerShell developers analysed the PowerShell Corpus of 400k+ scripts collected by Lee Holmes and Daniel Bohannon for security threat research[2][3] and said "I found that about 62% of variables that have ? in them use it in the end. That made me lean towards not introducing a breaking change." - in the comments on a pull request[4]. Then someone else made another analysis of the corpus with regex and came up with 329 out of 22,000,000 of variables have a potentially clashing "?" at the end.
It's been reopened as another discussion[5] and another person came up with an analysis of the Corpus with proper tokenising/parsing[6] and came up with 11 variables ending in ? out of 1,896,983 unique variables used[6] which then narrowed down to 1 that might break in backwards compatibility if this change happens. Coming up 4 years of back and forth discussion, even with that kind of evidential backing, with 2 core developers, the Team Lead and Bruce Payette one of the original developers weighing in against, being brought up in a community call, then flagged for review by the committee, then reopened as a reminder again[7] the team is still not won over on the risk of breaking backward compatibility by changing ? parsing at the end of a variable name.
That is, yes "possible not forward compatible for future parameter addition", especially by third party modules who might not take it as seriously, but not at all casually by PowerShell's developers.
[2] https://www.fireeye.com/blog/threat-research/2017/07/revoke-...
[3] https://aka.ms/PowerShellCorpus (1.2GB compressed)
[4] https://github.com/PowerShell/PowerShell-RFC/pull/223#discus...
[5] https://github.com/PowerShell/PowerShell/issues/11379
[6] https://github.com/PowerShell/PowerShell/issues/11379#issuec...
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
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.
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.
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.)
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?
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.
Your two comments in this thread contain one fine, substantive statement: "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." If you had simply replied upthread with that in the fist place, it would have made a fine comment with a very high signal/noise ratio. Unfortunately the rest of both comments is just noise, tanking the ratio.
As I explained upthread (https://news.ycombinator.com/item?id=25862312), the internet is crazy-making this way, but it's not some property specific to HN and it's not something that's somehow changed lately. It's intrinsic to the medium, and we all need to build our skills in coping with it—which includes not reacting from a provoked place. That's not easy, but it's necessary to the sort of community we're trying for here, and we need everyone to work together on that.
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 :|
(Probably, if I did it all the time, I'd get it right every time. Just like creating and using COBOL variables.)
PS is more powerful than Bash, it really should be faster to write a function body in it.
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.
So change it:
Set-PSReadLineKeyHandler -Chord Tab -Function Complete
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
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/cpJeezus.
If you didn't know what it was, how would you figure out what `$(expression)` means in bash for example?
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.
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.
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).
It's a shame because the rest of Powershell is so good.
However, you can always shorten parameter names as long as they remain unambiguous with other parameters, so
Get-ChildItem -Recurse -Include foo
ls -r -i foo
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.
Remove-Item -r -fo ./path/to/some/directory
For instance in powershell you can also do:
ls -r foo1. 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?
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.
MS technologies have sometimes been a bad investment for Windows developers too.
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.