Repository navigation
Need a way to bring back legacy Windows aliases for consistent experience #3610
Description
To address #929 we removed aliases that collided with native tools. However, some customers may want the legacy Windows PowerShell aliases because they are consistent with what they are used to. Proposal that has been discussed is to have a module that only contains aliases that users can import to get back that previous experience.
Activity
dchristian3188 commentedon Apr 21, 2017
Where should this new module go?
Gaelan commentedon Apr 21, 2017
It's not about "what we're used to." I'm a Mac user that has barely used PowerShell at all on windows. If I switched to powershell, it would be for the object-oriented model. My expectation is that
lsgives me a stream of objects, because that is powershell's killer feature. Without that, PS is nothing.bgshacklett commentedon Apr 21, 2017
Gaelan Steele (@Gaelan) for your use case, I would suggest using
Get-ChildItemorgcias the short form, meant for interactive usage. I understand that it can be difficult to retrain muscle memory (I'm having trouble myself), but being explicit with what your asking the shell to give you is almost always going to give you a better experience than relying on aliases which were not originally intended for your platform. The decision to remove these aliases has not removed any functionality in PowerShell, but only changed the way the commands need to be invoked.lscertainly falls into a grey area, as it's a built-in in both PowerShell and Bash, but in the case of commands such ascurl,wget, etc. which mask functionality that already exists on the system, I don't think there was really any question of what the "correct" behavior is, only the least disruptive. There was no solution that was going to be ideal for everyone. At least with this solution you will have an easy option to re-enable the aliases you wish to have in your environment.iSazonov commentedon Apr 21, 2017
David Christian (@dchristian3188) If your question was about a module place I believe it is https://github.com/PowerShell/PowerShell/tree/master/src/Modules/Shared
joeyaiello commentedon Apr 21, 2017
Putting them in a module is only one proposal. The point is that there needs to be an interactive (and possibly also parse-time) mechanism for turning GNU/POSIX colliding aliases on and off. (Side note: it's not just *nix users who may want to turn them on, Windows users may also want to turn these aliases off.)
joeyaiello commentedon Apr 21, 2017
Also, current thinking is that this might be blocked on PowerShell/PowerShell-RFC#48, which is why I'm removing
up-for-grabsand personally prioritizing driving that RFC to completion (it's blocking other usability issues as well).SteveL-MSFT commentedon Apr 21, 2017
chuanjiao10 for cmdlet name collision, we already support that today:
Microsoft.PowerShell.Management\Get-ChildItemjoeyaiello commentedon Apr 24, 2017
chuanjiao10: That might be the behavior you want, but you received far too much feedback on day one that people want things like
ls -lato just work out of the box. (Side note: the full path to the binary will always work, no matter what path we take here.)The fact that you have a preference is why we're proposing that there be an opt-in mechanism for exactly the behavior you're describing.
Sound reasonable?
Also, the reason your example is failing is because we need to implement globbing with #954
iSazonov commentedon Apr 26, 2017
Is here a way to explicitly start external (OS) command?
This is start cmdlet:
Can we do somethink like:
$nativecommand:whereIt can help with globbing and native pipes.
bielawb commentedon May 10, 2017
Ilya (@iSazonov) - I believe that can be done with Get-Command:
SteveL-MSFT commentedon May 10, 2017
chuanjiao10 the globbing issue you have above should be fixed in beta.1
SteveL-MSFT commentedon Jan 25, 2018
Closing this as the work will be done in https://github.com/PowerShell/WindowsPowerShellCompatibilityPack