8000 Need a way to bring back legacy Windows aliases for consistent experience · Issue #3610 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]
Skip to content

Need a way to bring back legacy Windows aliases for consistent experience #3610

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
SteveL-MSFT opened this issue Apr 20, 2017 · 15 comments
Closed

Need a way to bring back legacy Windows aliases for consistent experience #3610

SteveL-MSFT opened this issue Apr 20, 2017 · 15 comments
Labels
Issue-Enhancement the issue is more of a feature request than a bug WG-Cmdlets general cmdlet issues

Comments

@SteveL-MSFT
Copy link
Member

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.
@SteveL-MSFT SteveL-MSFT added WG-Cmdlets general cmdlet issues Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors labels Apr 20, 2017
@SteveL-MSFT SteveL-MSFT mentioned this issue Apr 20, 2017
Closed
@dchristian3188
Copy link
Contributor

Where should this new module go?

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

@bgshacklett
Copy link

@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
Copy link
Collaborator

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

@joeyaiello
Copy link
Contributor

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 joeyaiello added Issue-Enhancement the issue is more of a feature request than a bug and removed Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors labels Apr 21, 2017
@joeyaiello
Copy link
Contributor

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
Copy link
Member Author

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

Microsoft.PowerShell.Management\Get-ChildItem

@joeyaiello
Copy link
Contributor

@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
Copy link
Collaborator
iSazonov commented Apr 26, 2017 •
edited
Loading

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
Copy link
bielawb commented May 10, 2017

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

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

@SteveL-MSFT
Copy link
Member Author

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

@andyleejordan andyleejordan mentioned this issue Jun 5, 2017
Closed
11 tasks
@mklement0 mklement0 mentioned this issue Jul 15, 2017
Closed
@iSazonov iSazonov mentioned this issue Jan 14, 2018
Closed
@SteveL-MSFT
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Issue-Enhancement the issue is more of a feature request than a bug WG-Cmdlets general cmdlet issues
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@bgshacklett @joeyaiello @bielawb @Gaelan @SteveL-MSFT @dchristian3188 @iSazonov and others
0