Powershell: Please remove **all** built-in aliases and put them in a module

[Jaykul]

We've suggested this before in the context of the discussion of the infamous curl alias, and in that context it was not done (although I don't remember why), so let me suggest it again now:

ALL built-in aliases should be removed from the shell.

1. A module should be created called "CoreAliases" which recreates all the aliases which are left in PowerShell Core when it's run on Linux or Mac OS.
2. Another module should be created called "CoreWindowsAliases" which builds on top of CoreAliases but adds ls and the other aliases that are currently missing on Linux and Mac OS, but not on Windows.
3. A third module should be created called "WindowsPowerShellAliases" which further builds on the first two to put back all of the Windows PowerShell aliases for which the commands are present in Core.
4. All three modules should ship in the installer (like PSReadline), so they're always present.

Then we can stop changing aliases one at a time, and never have another discussion about them.

If people want the aliases, they just import the appropriate module for their situation. If they don't, they do nothing.

[Jaykul]

It's been very frustrating each time I type ls or cd in a console and the wrong thing happens.

Now at the eve of GA, yet another alias has been removed: sc

It's time to put an end to the madness, and just clean the slate so this can't ever happen again.

[iSazonov]

@Jaykul Thanks for the short and clear thought. I totally agree that the time has come and we have to complete this story that lasts two years.

Related #214 #3610

Based on previous discussions we know that some users want all the Windows aliases, some ones only part, some ones do not want them at all. We have also come to the conclusion that aliases only make sense in an interactive session and should (must) be excluded from scripts.

So I see a simple solution that we can implement in steps:
Step 1. Create compatibility modules (I suggest use Compatibility- name prefix for them):

• The first only aliases without conflicts (current list which we use now) (Compatibility-Aliases-DefaultSet)
• The second includes all aliases from previous module and curently excluded Windows PowerShell aliases (Compatibility-Aliases-ShortWindowsSet).
• The third includes all Windows PowerShell aliases (Compatibility-Aliases-FullWindowsSet).

Step 2. Import these modules only in the interactive session. We could add a new setting InteractiveOnly = $true to a module manifest. This feature will be useful for all compatibility modules and PSReadline. (Related #3956)

Step 3. Enable an user to choose which compatibility module to download or not to download at all using a configuration file (we already have powershell.config.json) and GPO. Until we implement the option users can load selected compatibility module using their profile file.

Step 4. Add an option to disable/enable aliases in scripts - enhance strict mode (run time) or/and using language aliases allow=$false statement (parse time). Add global option (to a configuration file powershell.config.json and GPO) to enable/disable aliases in scripts.

[Jaykul]

You're making this way too complicated.

There's no need for any functionality to be added in order to remove the default aliases -- even a setting to say which module to import would be overkill when we have profile scripts.

I'm not trying to get the alias _feature_ removed. I use aliases, and I want to keep using them. I don't want to loose the ability to change the name of commands.

I just want to clean out the defaults and give _existing users_ an easy way to load the aliases they're used to. In an ideal world, I want to do all of that without breaking anything more, although obviously we'll need users to add the Import-Module line to their profile.

The main point is to ensure we never _again_ break people's experience by such a silly trivial change as removing a built-in alias.

P.S. I honestly don't think you can get a new setting added to module manifests. We still don't have a setting to indicate the supported Edition or Operating System, nevermind something as meta as whether the author thinks the module should be used interactively.

[iSazonov]

Yes, it is long way. We have a lot of discussions aliases. As we have saw, any partial solution raises new issues, problems and discussions. We need to generalize all these discussions and create a common roadmap. I suggest such roadmap. The first step closes this Issue. The next steps close other problems - we should implement all operations - add, delete, modify, update, allow, disallow - in interactive session, in scripts, in remote access.

[iSazonov]

I get this from Windows Insider mail:

Windows Command line Toolchain includes bsdtar (tar) and curl. These two popular command line tools from the Unix shell are now available in Windows and Windows Server. bsdtar provides handy extraction/creation of compressed files and curl offers data transfer capabilities so you can download files from a remote location. (Build 17063)

We removed curl alias in a timely manner! :-)

@SteveL-MSFT I think it's one more argument that it's time to cut this Gordian knot.

[dragonwolf83]

I think it might be good to have a symbol to put in front of an alias to invoke using it. That adds one character for typing an alias and allows for keeping some sane defaults. Since we are going for breaking, might as well make it a useful breaking change.

To be honest, the only aliases I care about are the *-Object aliases. I wonder if they are the most commonly used since I tend to see Select -Property rather than Select-Object -Property.

[Jaykul]

Well, removing curl in PowerShell 5.1 would have been a lot more timely, considering 😉

I definitely agree that Select, Where, and ForEach are the most common aliases that get left in scripts -- because they're basically more readable than the full commands 😕

But I have to repeat, again, I don't want to break anything. I'm trying to _stop_ breaking things, by moving the aliases into modules where nobody will have any excuse to change them anymore.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this. We agree that users should easily customize their environment in regards to aliases. We ask that an RFC be authored capturing all the details of the proposed modules to understand the trade-offs and implications. RFC should include alternate considerations instead of a module: script, part of powershell.config.json, etc... Note that if the aliases are exported as part of a module, then auto-module loading will automatically find them so not clear if that is the desired behavior.

[DanielSSilva]

My two cents - While doing some research about alias, I've found some more commands that are native on Unix and are being "mapped" as alias, such as

clear
echo
kill
pwd
type

[pauby]

We ask that an RFC be authored

Has this been picked up as yet?

[iSazonov]

I hope to do it in the coming days.

[pauby]

@iSazonov That's fantastic. If you need help in any areas let me know and I will do what I can.

[iSazonov]

@pauby Done.

[kjacobsen]

Has any testing been performed to determine the impact of removing the cd alias? There is a feeling in my gut that we might introduce significant issues to interactive sessions. Its just a gut feeling, so could be totally wrong and would be happy to be wrong.

[kjacobsen]

Next thought. What about the help alias. How many new starters to PowerShell, myself included, started by just typing help and starting there?

[iSazonov]

@kjacobsen help is a function not alias.

The plan is to create tools for flexible aliases management without changing the current behavior. This will allow users to choose a convenient way to work. A separate question is about the default settings - that would be PowerShell Committee's decision.

[kilasuit]

@kjacobsen - technically @Jaykul is asking for a built in way of managing alias versioning and allowing you the user to maintain which aliases you want by giving you the ability to control this in your own scripts/modules/profiles

@iSazonov - by moving them to modules the "Default" becomes less and less relevant in my view, at least to the power users, however getting it right for the general user is something that I do agree needs to be thought of properly.

[iSazonov]

Some default values will always be present. :-)

[ExE-Boss]

Well, the curl and wget aliases have been permanently removed in PR #5268 and Windows 10 now ships with curl.exe. ✌️🏻⁠😄⁠✌️🏻

[Jaykul]

@SteveL-MSFT I assume this is being closed for inaction / failure to create a follow-up RFC?

[iSazonov]

I wonder too.

[SteveL-MSFT]

@Jaykul further discussion should be in a RFC, since there have been no additional comments here it doesn't seem necessary to keep this issue open. We've been trying to be more digilent on closing issues so we know which ones are actually still active.

[iSazonov]

I set Resolution-External implying that the discussion should be in the RFC.