> 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.
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.