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.