Add Weak Alias RFC

[lzybkr]

This change is

[DrPizza]

This just trades one breaking change for another. I agree that it's less common that someone will have curl or wget in %path% on Windows, but I do (because they're useful tools), and virtually every *nix user will have one or other or both in $PATH, so existing scripts are still going to break.

I think it's time to recognize that the "mimic" aliases have never been satisfactory. Their imitation of the real commands (whether cmd.exe built-ins or unix standalone programs) has only been superficial, and as such they've never been anything more than a crutch to work around some of PowerShell's verbosity. If you really want wget or curl, if you're familiar with their options and capabilities, the aliases are useless anyway.

The way forward should be staged deprecation and then removal. Something along the lines of:

v.Next: the mimic aliases on by default, some kind of deprecation warning on use, and a single switch to disable them all
v.Next +1: mimic aliases off by default, some kind of deprecation warning on use, and a single switch to enable them all
v.Next +2: mimic aliases removed entirely; if you want to reinstate them you'll have to add them to .bashrc yourself.

The only aliases that PowerShell should provide by default are those that are in the PowerShell vernacular; aliases such as iwr and gci, which provide short-hand for PowerShell commands without the misrepresentation that the likes of the curl and ls aliases impose.

[lzybkr]

The wget/curl aliases don't exist in PowerShell Core - they are specific to Windows PowerShell - so discussions about *nix don't apply to this RFC.

[DrPizza]

Surely whatever solution is chosen must result in consistent behaviour across both Windows and Core?

Otherwise, what's the use?

[riverar]

@DrPizza and I came to very similar solutions for apparently very similar reasons. The Weak Alias proposal simply moves the problem around and creates new harder-to-debug ones. Strongly suggest scrapping this idea and simply begin the sunset of built-in aliases across platforms.

PowerShell Current

• Aliases available, normal behavior

PowerShell vNext

• Aliases available, normal behavior, use emits deprecation warning
• Introduce -UseOldAliases:yes option to silence warning

PowerShell vNext+1

• Aliases unavailable, new behavior, use emits 'behavior changed' warning
• User can use -UseOldAliases:no to silence warning

PowerShell vNext+2

• Aliases unavailable, new behavior, no warning
• User can still use -UseOldAliases:yes until some determined obsolescence date

[lzybkr]

Yes, the proposed feature will work as described on all versions of PowerShell.

I think my RFC only proposes using a weak alias for curl and wget and an obscure PowerShell _mis_feature.

If the community sees value in applying weak aliases to other aliases like ls or ps, then consistency across PowerShell Core on Windows and Windows PowerShell becomes an issue.

[DrPizza]

I took at as read that the same issues arise for all those other bad aliases, and that any solution to wget and curl needs to be generalized. I suppose that others may disagree on this point. I feel that creating special behaviour only for two aliases will make things overall more confusing rather than less; "why does wget prefer the real executable when ps does not?"

[Stanzilla]

Agree with the pizza and the sideways head.

[DrPizza]

I also don't fully understand why scripts don't start from a fully clean environment; aliases have a role in interactive use, but surely not anywhere else.

[dragonwolf83]

I somewhat agree with you @DrPizza but not fully. Curl and wget should definitely go at this point. However, many aliases are beneficial to discovery and use while others are only a hindrance.

Invoke-WebRequest is easily discoverable that it is intended to do something with Web pages. Get-ChildItem is not! Having it alias to ls and dir make it much easier to start figuring it out a basic command that most of us grew up with. As long as you can get to real ls in the end, it helps get you immediately up and running.

Thinking on the fly here....
A good compromise with Alias use in general could be a first-use tour of PowerShell. You rcan run PowerShell for first time under your user profile you get aliases on by default. You type ls command and Get-ChildItem runs with a note at the bottom that the real name is Get-ChildItem and to please use that. Give an option to keep the the alias as well.

Moving to use aliases only for Interactive Terminal is a good idea too, but again depends on alias. I use %{ }, Select, and Where extensively. %{} may not be easily read as ForEach-Object but it greatly helps code readability when you have to do 5 of them consecutively. Select and Where are much easier to read than Select-Object and Where-Object.

I think we need to put all the aliases up for review and block them into categories on how to handle.

[lzybkr]

I've locked the conversation. Our RFC process is to use an issue for the discussion, in this case #16.