> 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.
> "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."
No they don't. a) you can remove the aliases, b) you can fully specify the name e.g. "curl.exe" wouldn't trigger the alias, or "c:\path\to\curl" wouldn't either. I don't remove the aliases, so I don't know why "remove-item alias:* -force" is so bad. The functions are, what, mkdir and more?
> "And they are absolutely worlds apart from the commands they alias— pretty much totally incompatible."
This is a complaint that "all things must be exactly how I expect them" which is not going to happen in a completely different shell/language/environment.
> "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'"
Yeah, no, command line utilities where I type "thing -h" and they go "-h doesn't exist. If you want help, type -help" suck. Thanks for nothing, technically correct but unhelpful nitpicking junk.[1]
What would you do if PowerShell had used "ls" and "grep" for its actual command names, not aliases, but they behaved differently from Unix shell `ls`?
[1] yes I am aware that it's not safe to type `-h` to random commands and expect it to be helpful and non destructive.
> No they don't. a) you can remove the aliases, b) you can fully specify the name e.g. "curl.exe"
I'm aware you can remove them, as my earlier comment clearly indicated by its description of how I remove them. Even in the example you give, adding '.exe' to the command name doubles the number of characters typed. Very ergonomic. They absolutely do prevent you from involing those commands by their names, just like any ordinary obstacle prevents you from doing things until you remove it.
> I don't know why "remove-item alias:* -force" is so bad. The functions are, what, mkdir and more?
There are 16 I remove on my system, but more if you also want to remove the aliases that clobber DOS commands and other legacy Windows stuff.
> This is a complaint that "all things must be exactly how I expect them" which is not going to happen in a completely different shell/language/environment.
lol. Nope.
> > "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'"
> Yeah, no, command line utilities where I type "thing -h" and they go "-h doesn't exist. If you want help, type -help" suck. Thanks for nothing, technically correct but unhelpful nitpicking junk.[1]
1. What you described is not what a command-not-found handler does. What you described is a shitty usage message.
2. What you described there is literally what actually happens if you run `mkdir -p`, `rm -rf`, `ls --help`, `ps -ef`, or `tee -a` in a vanilla PowerShell configuration. lmfao
And (2) is why aliases that clobber common external utilities with radically incompatible alternatives are only even potentially useful to people who (a) never use a command with any flags or options at all but (b) already 'know' how to use it, which are damn near non-overlapping groups.
> What would you do if PowerShell had used "ls" and "grep" for its actual command names, not aliases, but they behaved differently from Unix shell `ls`?
They sort of do this already with `mkdir`, which is a whole shell function and not an alias (and has to be removed differently). But if it was like, say, Get-ChildItem, and distributed as a built-in Cmdlet, it'd be harder to deal with. Truthfully, I would probably just not use PowerShell. But one could also rig up aliases for all of the GNU coreutils and other clobbered externals with a super short prefix, like ',' or something like that.
I don't really mind unconventional shells. I've been running a deliberately non-POSIX shell as my daily login shell on every system I touch for more than a decade, and some time in the next decade I'll probably switch to an even more exotic shell (inspired by PowerShell, even!) like Elvish or Nushell.
I even think it could be great for such a shell to bundle replacements for everything in GNU coreutils and more, so that scripts can be more portable. But they'd probably have to be clones of the GNU implementation for me to really get onboard with that. I know them pretty well and I like them, to the point that I always take them with me and put them directly on my PATH when I have to use macOS, clobbering the slightly-different native implementations. (But those slight differences are way easier to contend with, and a much smaller annoyance for me than PowerShell's default behavior on Windows.)
> yes I am aware that it's not safe to type `-h` to random commands and expect it to be helpful and non destructive.
That's also a major annoyance to me, to the point that I won't use some software that acts that way. Unix commands that do things other than print a help message for `--help` frankly don't belong on any system I administer. I don't fuck with Bernstein's daemontools because I don't like its argument parsing (no long options, -h does things other than print a help message), for example. I'm not a big fan of some of the classics either, like `tar` and `ps`, and will probably some day try to get used to some alternatives that use more 'normal', argparse-y flags and options.
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.