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.

[tmintner]

In general I support the RFC. That would be a short term fix. In the long run it would be better if invoke-webrequest provided all of the same functionality as curl. Windows Administrators have had to deal with other changes from commands that were built into the OS. For example, dir /s was an important command pre-PowerShell and we had to adjust to using dir -recurse because dir is an alias for get-childitem.

Another option would be to modify the invoke-webrequest cmdlet to look to see if you are on a *nix system and if so if there a parameter error then actually make the call to the curl binary with those parameters. This would allow the functionality to stay the same as it is now for those using the curl alias and also allow the use of the curl binary. The performance impact should be minimal.

[GeeLaw]

This workaround is even worse.

As pointed out in the RFC document:

Windows PowerShell updates as part of Windows, possibly breaking users of scripts that don't know how to fix the script

This difficulty comes from a user who uses scripts but cannot fix a script. It is more than possible that such a user also uses cURL, or use a batch script that relies on it. This is a scenario you cannot fix.

I do not think we have to be so upset resolving this issue as everyone out there knows the rule now. And it is costly to compromise backward compatibility since there are scripts no longer maintained by anyone. For now, I think we can implement Deprecated flag for aliases and when invoked, always show a warning (not Write-Warning as the user might set $WarningPreference to Stop).

PowerShell currently makes everything in/out a native utility string. While this works for some people, it won't work if you cannot decide the encoding of the input/output like you can do in Set-Content and Get-Content. For now, invoking native utilities should be done via Start-Process where you can control the standard streams binarily (by storing them in files and accessing the files with Get-Content and Set-Content).

I think we eventually will have binary pipe and this should happen in near future with the power of community. Like there is not much sense in piping objects into/out of native utilities, there is also not much sense in using the binary piping syntax with cmdlets/functions. When the binary piping is used, PowerShell should search native utilities and aliases of native utilities only (or at least before searching cmdlets/functions/aliases of them). This will virtually resolve all sensible scenario where cURL is invoked.

[dlwyatt]

I think we eventually will have binary pipe and this should happen in near future with the power of community. Like there is not much sense in piping objects into/out of native utilities, there is also not much sense in using the binary piping syntax with cmdlets/functions. When the binary piping is used, PowerShell should search native utilities and aliases of native utilities only (or at least before searching cmdlets/functions/aliases of them). This will virtually resolve all sensible scenario where cURL is invoked.

I'm not sure what you mean by a "binary pipe" here, or why that would affect command precedence, but changing command precedence in this way would be such a massive breaking change that it will never happen. (Consider all the discussion that had to go into just removing two fairly little-used aliases, by comparison.)

[dlwyatt]

My main concern with the weak alias proposal is that cURL and/or wget already exist on many Windows systems. For example, there's a copy of curl.exe on my path as part of msysgit / Git for Windows. Granted, it wasn't shipped as part of the OS, but it still means the weak alias proposal may not help as much as you'd think.

[dlwyatt]

Another option would be to modify the invoke-webrequest cmdlet to look to see if you are on a *nix system and if so if there a parameter error then actually make the call to the curl binary with those parameters. This would allow the functionality to stay the same as it is now for those using the curl alias and also allow the use of the curl binary. The performance impact should be minimal.

Unfortunately, this sort of change would have to happen right in the PowerShell engine (which is a pretty ugly hack). The Invoke-WebRequest cmdlet's code won't even start to execute if you pass it parameters that don't match its metadata.

[dlwyatt]

Personally, I'd be in favor of just sticking the Obsolete attribute on these aliases (and adding plumbing to the engine to write warnings if an obsolete alias is executed, assuming it doesn't exist already) for a while, and eventually removing them in a future release. It's a breaking change, but one with plenty of warning time for people to get their scripts sorted out.

The workaround is a clever idea to try to have it both ways, but will likely just introduce more confusion for users when scripts suddenly stop working after some other software package is installed.

[bladeoflight16]

The real underlying problem is that because this alias exists, the term curl is now ambiguous in PowerShell. This RFC does nothing to lessen the ambiguity. Instead, it's an ugly band-aid that introduces more complexity and is likely to solidify the current aliases instead of discourage their usage. If you're going to address the problem, it needs to be in a way that lessens the ambiguity. Additionally, this ambiguity is likely to throw someone off or create a subtle (although perhaps uncommon) bug.

This also reveals a sort of underlying problem in how PowerShell development is being managed as well: there seems to be no path to deprecating features for removal in a future version. You cannot provide backwards compatibility indefinitely and expect the system to remain clean. So maybe before addressing these aliases specifically, we need to ask the question, "How do you deprecate and remove or significantly alter features?"

Python has what I consider to be a decent model to consider on that front: the __future__ module. Consider the division functionality. That was a major breaking change, but by allowing developers to enable it in older versions before they migrated to the new one, they allowed developers to start coding against that functionality immediately. The end result is that now, a few years later, the old usage has fallen out of favor and is discouraged, even in the versions where it's available. In other words, it was a success: Python was able to make the breaking change of doing away with integer division without blowing up the community's code in one fell swoop, and the community adapted to the change. Scripts/libraries that still rely on it are now aged and unmaintained to the point that most developers wouldn't even consider using them.

Could something similar be done here? I envision a command or something similar that would remove the aliases in current versions, but in a future version, it would become a no-op because it's the default. It should also just pass if the aliases were removed manually. I would even go so far as to say it should disable all aliases in scripts. I tend to agree that when you're writing code to be run elsewhere, it's better for it to mean exactly what it says. Someone pointed this out in the other issue. This could be implemented in a manner similar to how #Requires works:

#DisableAliases

$var1 = 'http://www.myurl.com/some/path'
$r = curl $var1 # Fails if curl is not installed

$x = gci .\some\path # Aliases like gci could fail, too

Or if you really want to mimic Python:

#Future DisableAliases

$var1 = 'http://www.myurl.com/some/path'
$r = curl $var1 # Fails if curl is not installed

It would be a little annoying to declare this in all my scripts, but not much more annoying that declaring they require PowerShell 3 or higher. This also significantly lessens ambiguity across the board and encourages the good practice of avoiding aliases in scripts.

If you're strongly against disabling all aliases, we could be a bit more selective:

#DisableAmbiguousAliases

$var1 = 'http://www.myurl.com/some/path'
$r = curl $var1 # Fails if curl is not installed

You could still have the additional #DisableAliases for all of them, for those of us who think avoiding them is best.

PowerShell somehow raising notices about the deprecation and impending removal of the aliases when they're used would be important. This would give the impending removal a good chunk of visibility, so users of scripts relying on it would be very aware that their scripts are going to break in a coming version.

This of course doesn't address when you're hacking at the command line. I'm much less concerned about this use case. Someone actively crafting their commands on the spot can fairly easily remove the aliases manually to avoid this problem. Again, that's annoying, but if we solve the problem of the scripts, then the aliases can be ditched completely in a future version. So that the annoyance would at least eventually be removed.

My paragraph about Python's __future__ also raises a point that's missing from your analysis of scripts on Github. How old, maintained, and used are the scripts you looked at? Downloads would probably be the best we can do in terms of looking at usage. I actually suspect those results would work against removing them, since scripts using them without removing the alias would be broken in PS 3+.

@dlwyatt You can edit your messages, you know. It would likely be better to combine them into one.

[kuldeepdhaka]

Im not sure how come my solution (comment) is MISSING from PowerShell/PowerShell#1901

The basic idea is to identify if the user is trying to use curl (correct usage) or WebRequest (incorrect usage)
this is for explanation purpose, i really want the next solution (i will comment) to be implemented.

alias curl="intelligent-curl-fix"

last-time-webrequest-was-used = false

def intelligent-curl-fix():
    use-webrequest = false

    if user-provided-no-argument:
        use-webrequest = last-time-webrequest-was-used
    elif user-provided-webrequest-style-argument:
        use-webrequest = true

    last-time-webrequest-was-used = use-webrequest

    if use-webrequest:
        PRINT_WARN "alias curl='Invoke-Webrequest' is incorrect, see http://blabla.foo/XYZ"
        # mantain backward compatibility
        CALL Invoke-Webrequest  USER_ARGUMENTS
    else:
        CALL curl.exe  USER_ARGUMENTS

[bladeoflight16]

@kuldeepdhaka I think your proposal shares many of the same problems as the current proposal itself. It introduces complexity and creates more ambiguity. It doesn't really solve the problem. It just puts an ugly band aid over it, likely to result in unpredictable/weird behavior sooner or later.

[kuldeepdhaka]

With extension to the above solution.
i want to make sure that only curl is called, if curl.exe is installed because that would make sure that future user only make call to curl.exe

as you can see, curl-exe-is-installed() will make sure only curl.exe is only called if curl.exe is installed.

alias curl="intelligent-curl-fix"

last-time-webrequest-was-used = false

def intelligent-curl-fix():
    if (curl-exe-is-installed()):
        last-time-webrequest-was-used = false
        CALL curl.exe WITH USER_ARGUMENTS
        return

    use-webrequest = false

    if user-provided-no-argument:
        use-webrequest = last-time-webrequest-was-used
    elif user-provided-webrequest-style-argument:
        use-webrequest = true

    last-time-webrequest-was-used = use-webrequest

    if use-webrequest:
        PRINT_WARN "alias curl='Invoke-Webrequest' is incorrect, see http://blabla.foo/XYZ"
        # mantain backward compatibility
        CALL Invoke-Webrequest USER_ARGUMENTS
    else:
        CALL curl.exe USER_ARGUMENTS

Edit1: fixed a minor mistake in code.

[kuldeepdhaka]

@bladeoflight16 imo it is more ugly, since the motivation is to fix someone else code with introducing changes in PowerShell. 👎

this script can reside external to PowerShell code to make sure user/designer can manually changed/remove (in future).

[bladeoflight16]

@kuldeepdhaka If you had bothered to read my post before yours, you would know what I think of the current proposal, and you would have seen an alternative suggestion that I feel would be better in the long run. I am not here to argue. Either be mindful of what's already been said and be courteous to people who disagree with you or don't participate at all, please. Thank you.

[kuldeepdhaka]

I dont understand why someone want to add weak alias (to be abused too in future?) when a little script can do the trick.

[kuldeepdhaka]

@bladeoflight16 so you want a beautiful looking solution just drop from heaven to solve the problem?
(imo) fixes are mostly ugly. they just try to override another ugly thing.

[kuldeepdhaka]

@bladeoflight16 i readed your post but you later added (edited) and added the actual long content.
adding text later and then saying "If you had bothered to read my post before yours, you would know what I think of the current proposal" is wrong! dont try to be dumb head!

[kuldeepdhaka]

@bladeoflight16 in future, the script can be remove to remove the backward compatiblity thing.
so, imo out of the 2 (mine and rfc), my solution should be more preferable to you because remove the weak alias thing will be more hard than removing the script.

[bladeoflight16]

@kuldeepdhaka

in future, the script can be remove to remove the backward compatiblity thing.

This is a false assertion. Once a piece of functionality exists, script writers will write scripts that will break if it is removed. Someone (perhaps a lot of people) will rely on it, and then we'll be having this discussion all over again.

[kuldeepdhaka]

@bladeoflight16 btw, your __future__ example of Python dont seems to fit in the context because

• the code is already written
• the problem is with Microsoft code, not with User code (since Microsoft dev made the wrong choice)
• solution should prevent future problem while maintaining current code compatibility

[DrPizza]

(although @jpsnover told me to comment on the issue apparently that is not preferred, so I'm copy/pasting my commentary here)

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.

[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.

(though I could be swayed for a few such as 'where' for 'where-object')

[riverar]

(pasting as well, both @lzybkr and @jpsnover provided incorrect guidance on Twitter)

@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

[kuldeepdhaka]

PowerShell should fully remove the all unix alias to Microsoft Windows commands.

claiming ls == dir (or anything) (or any other util) is wrong because both of them are different.
If someone is insisting hard for the incorrect alias, provide another script and installation procedure.

just because ls or ps or curl or wget isnt Trademarked like Microsoft Windows is,
Microsoft shouldn't abuse the community.

If Microsoft is now trying to do (or something similar)
alias foo="foo1,bar,rat" (try foo1 first, then bar and then rat)

alias curl="curl.exe,Invoke-WebRequest" (if curl.exe not found, use Invoke-WebRequest)
is still trying to abuse the community.

because if curl.exe is not installed, then user (will unknowingly) use Invoke-WebRequest.
this is (imo) embrace, extend, extinguish because what if Microsoft could/did not bundle curl.exe with PowerShell?

[kuldeepdhaka]

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

just place some compatibility code that make sure older code work as expected (for now).
and in next major release, even that compatibility thing is removed too.

[bladeoflight16]

@DrPizza @riverar I favor (and proposed above) a script level control similar to #Requires over a command line switch to PowerShell. The switch could also be introduced if you want to add it to your OS level shortcuts, but I don't think that the command line switch is enough. The scripts themselves need to have the ability to declare whether these aliases should be available in their scope. If the script can't declare it, then you have to rely on users to pass it in, and one of the major problems deprecating this "feature" is that end users are likely to experience breakage they have no ability to fix (at least supposedly).

[riverar]

@bladeoflight16 That sounds reasonable to me. Maybe this and a reg flag would do (to cover scenarios where PowerShell and scripts are embedded in some LOB app).

[lzybkr]

@kuldeepdhaka - You can submit a new RFC to remove aliases, but this RFC is not for that discussion, this RFC is to discuss the merits of a weak alias that might be used for multiple reasons, one of which is to mitigate usage of curl and wget.

I considered your approach of introducing a proxy function - on the surface it seems like an option. The biggest issue is there are real world examples where the usage is ambiguous - a proxy doesn't help at all in such cases.

I would also expect other complexities to come up a proxy - e.g. not getting the argument parsing just right. I'm more confident that alias can be implemented in a simple way.

[lzybkr]

@bladeoflight16 - I think it's reasonable to propose a new RFC to disallow aliases in scripts, but let's keep the discussion on the pros and cons of this specific proposal.

In PowerShell V5, I introduced the using keyword with the intention of adding something like using strict ... for scenarios just like this - so if you do write an RFC, I suggest you use that syntax.

[kuldeepdhaka]

@lzybkr i DONT thing you are trying to mitigate the curl, wget issue.
weak alias are another way to make sure user again make mistake of thinking curl == WebRequest

im getting a foul smell and this time it would be even more hard to claim that it is wrong.
just if questioned, in reply Microsoft can say well, we are calling curl.exe first and then WebRequest.
but even if curl.exe is not installed, WebRequest != curl.exe.

The side effect of weak alias will create problem for the community in future.

[SteveL-MSFT]

Looks like the PowerShell Team be meeting on Tues (8/30) instead of today. As long as this RFC is open, continue posting comments. Thanks.

[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@git.luolix.topmailto: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//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 PowerShell/PowerShell#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@git.luolix.topmailto: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//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 #16 (comment):

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 - #16 (comment) )
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.)