RFC0007-Weak-Aliases comments

[lzybkr]

[PowerShell Committee has Rejected this RFC, see decision for details]

This issue is to discuss the weak aliases RFC.

This proposal helps address issues related to the curl/wget aliases introduced in PowerShell V3.

The discussion should focus on the strengths and weaknesses of this specific proposal and on avoiding or minimizing breaking changes. Ideally, existing scripts should continue to run without any changes when a new version of Windows PowerShell is installed.

Note that doing nothing is the only way to completely avoid breaking changes - the goal of this RFC is to find a compromise.

This RFC does propose a breaking change, but only in scripts where curl and wget are meant to call Invoke-WebRequest but curl.exe or wget.exe are found via the path. We don't have data on how often this might be an issue - but if a future version of Windows installs curl.exe and wget.exe by default, then it may be pointless to implement this RFC as that would be equivalent to removing the aliases.

[doubleyewdee]

Progressively marking "sham" aliases as deprecated with increasing warnings prior to removal seems like the best path to me. Informally speaking to many I know who have tried and given up on PowerShell as an interactive shell there is a common theme: "the aliases do not do what I mean." Simple memorized keystrokes ('ls -l', 'dir /s') do not do what the user expects and heavily violate POLA.

Weak aliases are an interesting solution here but I would be more in favor of simply removing these malapropos entirely.

[be5invis]

Wait, I have to type copy, or even copy-item in the future? Instead of removing aliases, why do not re-implement these names into a parameter-compatible typed version? Like, ls will be a wrapped get-childitem with parameter-to-parameter compatibility to the Unix one (/bin/ls), while its output is typed.

[rkeithhill]

@be5invis The "PowerShell" alias for Copy-Item is cpi. It's just one more character than cp.

[be5invis]

One keystroke for a command used hundreds times per day is many.

???? iPhone

? 2016?9?4??08:19?Keith Hill notifications@github.com<mailto:notifications@github.com> ???

@be5invishttps://github.com/be5invis The "PowerShell" alias for Copy-Item is cpi. It's just one more character than cp.

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/PowerShell-RFC/issues/16#issuecomment-244577057, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAOp29STwrTx6Dv-OD9PZ84BKanFJtjMks5qmg6IgaJpZM4JtRqn.

[bladeoflight16]

@joeyaiello I think a key word that your summary of the analysis/discussion misses is "ambiguity." It's ambiguous what a weak alias would mean. It would call different things on different machines, leading to unpredictable behavior. That unpredictability means that you can't depend on the alias to work across different machines, both at the command line and in scripts. How is an unreliable alias any better than just removing the alias entirely? I don't think it is. Everyone would still need to stop referencing it to get predictable behavior, so what does it accomplish?

[Jaykul]

@be5invis no matter what is decided, you will always be able to put set-alias cp copy-item in your profile script (or even set-alias c copy-item).

In fact, I would hope to see an aliases.ps1 (or separate linux and cmd specific alias files) shipped to let you re-load them easily ...

[SteveL-MSFT]

As discussed by the committee, closing this issue as no more comments needed for this rejected RFC

[kuldeepdhaka]

@Microsoft @jpsnover @SteveL-MSFT Nice trick. You were waiting for the community to settle to silently close the RFC. if you remember the original issue https://github.com/PowerShell/PowerShell/pull/1901 has 900+ up votes for the PR commit message.

You promised to fix the issue when the issue was at peak and now shamelessly "rejected RFC". !?$#!

[brabo]

nice one, this is exactly how much you care about open source and the community. no surprises here...

[be5invis]

It is not solving the problem. The true solution may be implementing a typed, parameter-compatible set of Unix tools.

???? iPhone

? 2016?11?17??21:47?brabo notifications@github.com<mailto:notifications@github.com> ???

nice one, this is exactly how much you care about open source and the community. no surprises here...

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/PowerShell-RFC/issues/16#issuecomment-261250426, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAOp20H0BDYUNaHCf-QzfifXrEMrXhK7ks5q_FrqgaJpZM4JtRqn.

[lzybkr]

@kuldeepdhaka - we are hardly silent here - the discussion is all public, and you can see the rationale for closing in the RFC itself.

As previously mentioned, and in line with your suggestion, the next major version of PowerShell (6.0) does not have (and in fact never had) the alias curl or wget.

[rkeithhill]

To be clear, the new open source implementation of PowerShell that runs on Linux, Mac, Windows does not define the curl alias.

[kuldeepdhaka]

@lzybkr @rkeithhill I will repeat what is said in https://github.com/PowerShell/PowerShell-RFC/issues/16#issuecomment-242591860:

need is, a full removal of unix -> microsoft windows utilities alias!

By full i means ls, cp, mv, rm etc. (All UNIX and similar platforms , not just curl, wget)

Possible pathway: Either implement unix compatible utilities in Powershell ( @be5invis - https://github.com/PowerShell/PowerShell-RFC/issues/16#issuecomment-261250796 ) OR Design PowerShell in such a way that user enable only these illict alias when they want (ie user choose - not by default. maybe a global checkbox in settings/preference that is unchecked by default).

What i see wrong is, Example: people will expect ls (Unix) to accept dir (Microsoft) argument (since PowerShell perform alias to ls -> dir). This will increase confusion and chaos in community in long run.

Just removing curl or wget alias is a quick escape, fix the damn problem for real!

ls, cp like utilities are like virtual estate that the community has build up in our computing history. We dont want companies to stick their bills (illict alias) on the virtual estate to increasing their popularity!

BTW, releasing the code under Open Source licence do not make these illict alias, less illict.

[be5invis]

@kuldeepdhaka I stick on making a new set of commands. Maybe you can do one first? though the implementation may be weird... A typed IPC protocol with native commands will solve every problem.

[rkeithhill]

By full i means ls, cp, mv, rm

Those aliases, along with curl/wget, have been removed from the Linux versions of PowerShell. I just checked the alpha.13 version for Ubuntu 14.04.

[be5invis]

@rkeithhill He's talking about the Windows version. This is the real "breaking" change -- there may be a lot of scripts are using them.

[KirkMunro]

@kuldeepdhaka Be smarter (and frankly, more respectful) about what you're requesting. Removing or changing the syntax of commands that have been in use in an environment for 10 years and that may be in production scripts (whether they should be or not is irrelevant) that companies depend on is not really an option, just as going back in time to make sure this doesn't happen isn't an option either. You're wasting the time of yourself and others as long as you're stuck on that point.

Even without considering Unix, within the Windows environment PowerShell has used aliases to make transitioning from cmd.exe, a Windows utility, easier. The dir alias is a great example of this. If you were used to running commands like dir /a:h or dir /o:-s those commands will not run in PowerShell; however, dir by itself will invoke a command that gives you back the directory listing for the current directory. Aliases have two purposes:

1. To help newcomers discover equivalent PowerShell commands; and
2. To make interactive PowerShell easier.

The first one of those two would probably be better served today by optional modules or code snippets or some other learning feature that would help users transition from one environment to another. But when PowerShell 1.0 came out 10 years ago, aliases made it a lot easier for users to begin PowerShell adoption, and when aliases were presented to users, they were presented as being different from their equivalent native command, as something that should not be used in production scripts, and as a learning tool. Fast forward to today, and you're coming in to PowerShell after 10 years of history, without interest in understanding the past nor the big picture behind the decisions that were made, after changes were already made in the Linux version of PowerShell based on this discussion to adjust how aliases are used there, and demanding changes that will break production scripts. How can you possibly expect to be taken seriously?

What is an option is for Windows PowerShell users to recognize the Unix command differences and modify their environment using a profile script.

For example, anyone wanting to make the Unix commands act more like Unix on a Windows system can install Cygwin and drop this in their PowerShell profile: https://gist.github.com/KirkMunro/badf56a4999dbbd77b6637f0f0c606be

That's easy for Windows PowerShell users to do, and simply requires some documentation/blog posts to help them discover why it is beneficial to make such a change. Asking for anything else related to changing the default behaviour of Windows PowerShell is nothing more than a waste of time.

[Jaykul]

You didn't want this fix anyway @kuldeepdhaka -- why are you moaning about it (especially all these months later?) Nobody liked this proposal, we need a different fix. Rejecting this proposal doesn't deny the problem.

[kuldeepdhaka]

@Jaykul I was waiting for people to implement the fix. so, i waited to see what comes out. Moral of the story: I have other work in life too.

Not fixing the problem is same as denying the problem. (and rejecting the proposal is the first step)

[kuldeepdhaka]

@KirkMunro Be smarter (and frankly, more respectful) Personally attacking isnt fruitful. Please! "illict alias" They are indeed illict!!!

If you are doing mistake for past 10 year of your life, will you keep repeating it just for the sake of hiding it?

What im saying is: in the next major release, Remove all alias from Powershell for UNIX (and other derivative platform) utilities to Windows utilities. Give option to user to enable these utilities only when they want (do not enable the alias by default). This will help keeping compatibility. (what you want)

To help newcomers discover equivalent PowerShell commands; and To make interactive PowerShell easier.

You are getting all the benifit by creating chaos, confusion and blurring the UNIX (and derivative platforms) taste and ease of use. Let people enable the facility by themselves.

Default setting has always been a powerfull tool (+ Microsoft dominant position on OS market.) Enabling these illict alias by default show Microsoft ill intentions.

[KirkMunro]

@kuldeepdhaka Every point I made in my last reply stands. There was nothing personal about it, and it wasn't an attack. The reply was an appropriate response to your comments on the thread.

You very clearly don't understand. Perhaps it's a language issue. Or perhaps you're not reading the replies that people post to you, nor really trying to understand the bigger picture. In either case:

1. On PowerShell for Linux, the aliases have already been removed, as was highlighted here. It's done. Over already. Do you understand that? (rhetorical question, please don't bother answer)
2. On PowerShell for Windows, the aliases remain, as they must because broad breaking changes cannot be permitted. Full stop. You need to stop wasting time on this.
3. Microsoft has not shown any ill intentions here whatsoever. None. Not even a smidge.

Anyway, while I thought I might be able to bring you some clarity on this subject, I'm done with this thread now. You can't please everybody. ¯\_(ツ)_/¯

[jaetwh]

Invoke-WebRequest wont work without IE because it's using IE behind the scenes, and that's also the reason for the bloated memory consumption of the command. And as a side note, EU has forbidden the browser to be shipped with Windows (MS rightfully got fined for including it). Users currently having strange problems with Invoke-WebRequest on lawfully installed systems because the browser components are missing. Please remove the command altogether, with its different aliases.

[bielawb]

@kuldeepdhaka it's illict to assume anything was done by MS (you probably spell it with $ at end, right?) here. All aliases that resemble unix/Linux commands are there because of muscle memory of PowerShell team members, and muscle memory of people who think about useful tools, not religious approach to them. I'm coming from Linux background and suffered for years from "ls: command not found". Adding these aliases to PowerShell (on Windows) was helping me (and others) who were using PowerShell on Windows to use muscle memory we had and get same behaviour from simple command calls: ls would list content in current location, cat would show content of item, and if I was lost about parameters: man would help me find my ways. And I could tab-complete parameters and because of meaningful names, I could easily guess their purpose.

Do I want these aliases to behave like same commands on Linux? HELL NO! I don't want to be forced to pipe results of any of them to grep to get any filtering, I don't want to pass several parameters to get whole objects back. I don't want to waste my memory on memorizing what -u stands for.

And if you prefer to use exactly same tools and get the same results yourself - nothing is stopping you from removing/overwriting these aliases on your system.

[kuldeepdhaka]

@bielawb Im saying:

Do not enable these alias by default, let people make their own decision (either a global option OR ~/.profile like mechanism OR any other method). i did not say they are useless/waste. But im saying these alias are designed with ill intention and enabled by default. In the long run, these illict alias will only hurt the community as a whole. (signs are already visible)

Illict alias should be dropped!

[SteveL-MSFT]

@jaetwh Invoke-WebRequest with PowerShell Core 6.0 doesn't depend on IE (try it today on Ubuntu which I assure you doesn't have IE).

@kuldeepdhaka the aliases have been removed from PowerShell Core 6.0 for awhile now

[bladeoflight16]

Recommend locking this issue. Clearly, no more discussion is required since the RFC was rejected, and if useful discussion goes beyond this RFC, it belongs elsewhere. (Importantly, locking would starve the trolls feeding here.)