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 https://github.com/PowerShell/PowerShell/pull/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. :-1:

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.

[kuldeepdhaka]

If weak alias is used for fixing the unix alias problem, im sure Microsoft is taping another embrace, extend, extinguish opportunity.

[and i will be (atleast personally) clearified that it is the same old Microsoft, nothing has changed.]

[kuldeepdhaka]

Please go on implementing weak alias (language feature) but don't claim it that weak alias will fix the unix alias problem. IT WONT!!! because the problem isnt just curl or wget, problem is: abuse of the trust of the community.

[dlwyatt]

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?"

That pretty much hits the nail on the head. If you try to be backward compatible forever, you become the mess that is Java.

We seem to be starting to embrace SemVer in the code, but part of that practice is that the user has control over when to upgrade, and which version to use. With PowerShell being automatically patched along with the OS, that's pointless. If PowerShell's release can be decoupled from Windows completely, and if versions can exist side-by-side, then we'd be in better shape to release breaking changes in a sane fashion without problematic workarounds.

[DrPizza]

@bladeoflight16

I favor (and proposed above) that a script level control similar to #Requires would be favorable over a command line switch to PowerShell.

Yes, that seems reasonable, though I think both would be better.

[KevinMarquette]

Because we are just talking about aliases here, can we pull them out of Powershell but create a module called LegacyAliases that can be easily loaded? Install-Module LegacyAliases

I know we are really focused on maintaining backwards compatibility but we already have cmdlet fragmentation on Powershell from one version of Windows to another. cmdlets not existing is something we already look for especially as we start to grow and use the community modules.

A second option is to remove them but make them available when Powershell is started with the -Version 5.0 param. We already have a 2.0 option. This would address the ungodly amount of legacy scripts out there that are full of these aliases.

Personally, I will really miss ls when it goes away and will have a hard time parting with it.

[dlwyatt]

That's why aliases like dir, ls, and cd were created in the first place, to help adoption of PowerShell for people who were familiar with other shells already. Muscle memory and all that. I still never type gci or sl at a PowerShell prompt, even years later.

[alejandro5042]

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

As a PowerShell user for 5+ years on Windows, I will be the voice of the developer who wants these aliases. I own hundreds of scripts used in daily development by 500+ people. Every day, they are being used more & more often. I am a PowerShell evangelist at my organization and I'm excited that this open source move to Linux & Mac means I don't have to rewrite my scripts in Python.

I use ls literally everywhere in my scripts. I love the brevity & power in aliases, both on the command line and in the text editor. I neither encourage nor discourage the use of aliases; in fact, I wish they were stronger (e.g. default parameters).

Being a Linux user as well, I am keenly aware of the differences between ls in Windows and Linux. I have no problem understanding that when I do curl in PowerShell, I will get an object--and a powerful one!--and when I want to be super sure I'm executing the executable (on Windows), I add .exe (curl.exe) and I'm good to go again. I have never had an issue.

I am curious whether the uproar is from current users, potential users, or people who actually have no real intention of using PowerShell.

I'm all for a proposal that would clarify if I'm calling a PowerShell cmdlet/alias or a native executable (e.g. a new operator) or even a script variable preference (like $ErrorActionPreference). But removing these aliases would be a step backward, IMHO.

[kuldeepdhaka]

@alejandro5042 you can still do, we are just making sure that people are not slapped with something that dont know (by default). that would only cause / is causing confusion to everyone as a whole.

[kuldeepdhaka]

@dlwyatt someone can maintain a small file that contain all your favourate alias. you can just drop/add it into your startup file and you have them. by default slapping, it will only cause confusion to everyone.

just think, what if bash start doing alias dir=cd (on Microsoft Windows) claiming that it would "help adoption" Im sure they wont, its against the community ethics

[dlwyatt]

just think, what if bash start doing alias dir=cd (on Microsoft Windows)

Don't make stupid arguments. Aliasing to a command that does something completely different is ridiculous. However, aliasing dir to ls could have been helpful to someone just learning bash after only having used the old windows cmd.exe, for example.

[DrPizza]

For me, the aliases have been a major stumbling block towards using PowerShell as a regular shell. To be clear, my personal interests are 99% interactive use, 1% scripting.

I resent that it lies to me. If it's gonna let me type 'dir' then it needs to let me type 'dir /s' and 'dir /a'; if it's gonna let me type 'ls' it needs to give me 'ls -la'. 'ps' needs to support 'ps auxfw'. The names set up expectations and PowerShell does not meet those expectations, and as such it continually sets me up for disappointment.

"But the PowerShell names are so wordy" you might complain. I agree, but this doesn't stop at the command name. The domain-specific vocabularies of real ls or dir or ps or curl are much more concise than their PowerShell equivalents. Your muscle memory may stop at the command name; mine does not. Let's stop pretending.

Yes, the iwr object may be technically more powerful than the text I/O of wget or curl. but wget --mirror is way richer than anything I can make iwr do.

[kuldeepdhaka]

However, aliasing dir to ls could have been helpful to someone just learning bash after only having used the old windows cmd.exe, for example.

@dlwyatt "someone just learning" not for everybody. doing the alias by default only make the ecosystem muddy.

[riverar]

Want to point out that Microsoft's official PowerShell extension for Visual Studio Code already emits warnings for alias use.

[dlwyatt]

For me, the aliases have been a major stumbling block towards using PowerShell as a regular shell. To be clear, my personal interests are 99% interactive use, 1% scripting.

I resent that it lies to me. If it's gonna let me type 'dir' then it needs to let me type 'dir /s' and 'dir /a'; if it's gonna let me type 'ls' it needs to give me 'ls -la'. 'ps' needs to support 'ps auxfw'. The names set up expectations and PowerShell does not meet those expectations, and as such it continually sets me up for disappointment.

The intent was never to reimplement all of those tools exactly as they existed in other shells. (Quite the opposite, in fact: one of the core philosophies of the PowerShell cmdlet is consistent parameter parsing across all commands, not having every command be its own special snowflake with regard to syntax and parameter passing.) But someone completely new to PowerShell can more easily find Get-ChildItem and Get-Process if they type a familiar command and it sort of works. Then dive in for more detail later.

Maybe it was the right decision, maybe not, but that's almost a decade in the past at this point. Helped me when I was learning, that's all I can say.

[kuldeepdhaka]

@DrPizza Yes, when we type a command, we have expectation from it. like typing ls i expect it to accept -la argument. dir don't accept -la so, that only cause the whole ecosystem to become muddy and full of confusion.

[kuldeepdhaka]

@dlwyatt it is a decade or whatever long decision, it was wrong after all, so need to be fixed. ls and dir are two different command.

using ls and dir inter-changeable in production code is not less than a joke

[kuldeepdhaka]

So, just because someone could start easily with PowerShell since they are familiar with other shell. alias cd=dir is getting into production code. HELL NO! DON'T DO THAT! PowerShell is getting benifited on someone else expense. It isnt ethical and not good for community either!

[dlwyatt]

dir is not, has never been, and never will be equal to cd. Why do you keep even typing that? I think I'm done replying to you, not even sure what point you're trying to make anymore.

[kuldeepdhaka]

@dlwyatt What im trying to point out is that: Instead of fixing the problem as a whole, Microsoft is making dubious to tell that they fixed the alias problem. Currently the proposed weak alias solution is as bad. It is just a fake solution to get away with it.

[KevinMarquette]

@kuldeepdhaka but to many of us, ls and dir are the same command now. I walked away from the cmd shell years go so the Powershell aliases are my new standard. I expect that when I am in Powershell that I will get the object orientated versions of those commands.

Thankfully I have adopted the verbosity of Powershell so there are only a few core aliases that are still a crutch for me. ls and sort are my worst offenders.

[DrPizza]

Maybe it was the right decision, maybe not, but that's almost a decade in the past at this point. Helped me when I was learning, that's all I can say.

I can agree that it helps for the first 5 minutes. But everything else about PowerShell is so wildly different, I feel this is pretty trivial. You're already going to have to learn an entirely new approach to using the command-line to use PowerShell, so I just don't know that gci instead of dir or sl instead of cd is really going to be make or break.

Back to the topic here: typing e.g. wget should have uniform behaviour across every environment; unix, Windows, scripted, interactive. I think that behaviour should be "call the external wget executable or fail if it's not found". Likewise curl. These commands are far, far richer than is appropriate to an alias.

I personally would extend this, at the very least, to ps and kill, and maybe ls/cp/mv/rm.

[kuldeepdhaka]

but to many of us, ls and dir are the same command now

Now, you think dir and ls same command.

They are two and will always be two different commands.

succeeded in embrace, extend, extinguish