Powershell: Need a way to bring back legacy Windows aliases for consistent experience

[SteveL-MSFT]

To address https://github.com/PowerShell/PowerShell/issues/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.

[dchristian3188]

Where should this new module go?

[Gaelan]

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 ls gives me a stream of objects, because that is powershell's killer feature. Without that, PS is nothing.

[bgshacklett]

@Gaelan for your use case, I would suggest using Get-ChildItem or gci as 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.

ls certainly falls into a grey area, as it's a built-in in both PowerShell and Bash, but in the case of commands such as curl, 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]

@dchristian3188 If your question was about a module place I believe it is https://github.com/PowerShell/PowerShell/tree/master/src/Modules/Shared

[joeyaiello]

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]

Also, current thinking is that this might be blocked on PowerShell/PowerShell-RFC#48, which is why I'm removing up-for-grabs and personally prioritizing driving that RFC to completion (it's blocking other usability issues as well).

[SteveL-MSFT]

@chuanjiao10 for cmdlet name collision, we already support that today:

Microsoft.PowerShell.Management\Get-ChildItem

[joeyaiello]

@chuanjiao10: That might be the behavior you want, but you received far too much feedback on day one that people want things like ls -la to 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]

Is here a way to explicitly start external (OS) command?
This is start cmdlet:

&"where"

Can we do somethink like:

$nativecommand:where

It can help with globbing and native pipes.

[bielawb]

@iSazonov - I believe that can be done with Get-Command:

$where = Get-Command -Name where -CommandType Application
& $where

[SteveL-MSFT]

@chuanjiao10 the globbing issue you have above should be fixed in beta.1

[SteveL-MSFT]

Closing this as the work will be done in https://github.com/PowerShell/WindowsPowerShellCompatibilityPack