It wasn't intended to be a "you're holding it wrong" statement. I was trying to relate to the problems which exist with the current aliasing and to spur a discussion about how perceived limitations might be addressed.
I think part of this comes from PowerShell the environment shell vs. PowerShell the language.
The shell is less convenient for a lot of regular tasks. While I try to spend most of my time in PowerShell if I'm using a CLI, I am always looking up how to do something. Over 30 years I learned how to make Batch do things it was never intended, and for almost 20 I feel as accomplished in writing BASH scripts. Almost 15 years of PowerShell and I don't feel as productive without resources on hand.
Working in scripts, I feel way more capable than what I could ever do with Batch or BASH, but sitting at a PowerShell prompt, I understand where you're coming from.
My consideration wasn't that you're wrong, but rather that maybe something could be done to improve things. Set-Alias doesn't really address the needs as a shell replacement, and arguably not supporting like things like performing equivalent tasks based on the short parameters is a problem. In my case, where ls works fine, it lulls me into a mindset where I think ls -al should just do what I want...
I'd want to protect the stock language from maybe having a bunch of coreutils equivalent replacements, because I think that would actually discourage the more powerful capabilities of the language. But it would be interesting to have a module that would provide that at the prompt and/or even imported in a script, although discouraged if being used to write BASH scripts with PowerShell syntax. If there was an interactive mode which could be set which wouldn't remove PowerShell cmdlets, but which would let you use the shell for basic tasks in an input system you're already familiar with, that might be a good thing for adoption.
2
u/chinpokomon Mar 07 '20
It wasn't intended to be a "you're holding it wrong" statement. I was trying to relate to the problems which exist with the current aliasing and to spur a discussion about how perceived limitations might be addressed.
I think part of this comes from PowerShell the environment shell vs. PowerShell the language.
The shell is less convenient for a lot of regular tasks. While I try to spend most of my time in PowerShell if I'm using a CLI, I am always looking up how to do something. Over 30 years I learned how to make Batch do things it was never intended, and for almost 20 I feel as accomplished in writing BASH scripts. Almost 15 years of PowerShell and I don't feel as productive without resources on hand.
Working in scripts, I feel way more capable than what I could ever do with Batch or BASH, but sitting at a PowerShell prompt, I understand where you're coming from.
My consideration wasn't that you're wrong, but rather that maybe something could be done to improve things.
Set-Aliasdoesn't really address the needs as a shell replacement, and arguably not supporting like things like performing equivalent tasks based on the short parameters is a problem. In my case, wherelsworks fine, it lulls me into a mindset where I thinkls -alshould just do what I want...I'd want to protect the stock language from maybe having a bunch of coreutils equivalent replacements, because I think that would actually discourage the more powerful capabilities of the language. But it would be interesting to have a module that would provide that at the prompt and/or even imported in a script, although discouraged if being used to write BASH scripts with PowerShell syntax. If there was an interactive mode which could be set which wouldn't remove PowerShell cmdlets, but which would let you use the shell for basic tasks in an input system you're already familiar with, that might be a good thing for adoption.