PowerShell should support dynamic aliasing of parameters

[JamesWTruher]

Summary of the new feature/enhancement

One of the things that I miss in PowerShell from my years of using *nix shells, is the ability to combine multiple parameters into a single one.
The easiest way to see this behavior is with /bin/rm where /bin/rm -r -f * is equivalent to /bin/rm -rf *.
While PowerShell has a way to create parameter aliases, it's a _developer_ activity, rather than a user activity,
which puts the responsibility on the developer to create a custom experience for the user.
We've done a pretty good job with parameter aliases, but I feel we still fall short.
I think this can be enhanced and improve the experience by providing what I like to call _Composed Parameters_.

Proposed technical implementation details (optional)

Here's what happens today:

PS> remove-item -rf *
Remove-Item: A parameter cannot be found that matches parameter name 'rf'.

I think this new behavior can be added to Set-Alias to include not just command aliases, but parameter aliases as well.
A new parameter set could be created for Set-Alias which provides the following behavior:

PS> Set-Alias -parameter rf -command remove-item -value @{ Force = $true; Recurse = $true }
PS> remove-item -rf *

The aliased parameter would be _preferred_, so the parameter binder would check the aliases _first_ and replace the aliased parameter with the provided values.
This implies that you could create a parameter alias as:

PS> Set-Alias -parameter f -command * -value { Force = $true }

which would prefer -force over -filter for commands like get-childitem, which might improve the experience further.

Note that this does _not_ address issues of ordering (rm -rf vs rm -fr), but much of these behaviors are muscular rather than cognitive; Fingers typing the same thing over and over, year after year, rather than thinking about it.

Note that this implies that not only the alias cmdlets would need change, but also we would need a way to store this information in the alias provider, but I don't believe this to be overly complicated.

A couple of further thoughts:

• What about multiple instances of parameters?
  
  
  
  • I think that we do simple replacements, which means that we would get a runtime error if we saw:
  
  

PS> Set-Alias -parameter rf -command remove-item -value @{ Force = $true; Recurse = $true }
PS> Remove-Item -rf -force *
Remove-Item: Cannot bind parameter because parameter 'force' is specified more than once. To provide multiple values to parameters that can accept multiple values, use the array syntax. For example, "-parameter value1,value2,value3".

• ScriptAnalyzer rules should be created to warn when this is done
  
  
  
  • I see this as an interactive behavior which should probably not be in scripts
  
  

[rjmholt]

Would it make sense to also include a similar behaviour with native commands and an argument array/vector?

[oising]

This could be a bit dangerous or at least ambiguously breaking -- this works in gnu land because single hyphen parameters are guaranteed to be one letter in length: Double hyphens are used for longer parameters. In powershell, we don't have that safety and partial parameter names (e.g. -fo for -force) may be shadowed by an alias that leads to destructive actions.

TL;DR Having global parameter aliases like above could have unpredictable effects with other cmdlets/functions imported later into the session.

[vexx32]

Yeah, I don't think this really makes sense for PS.

If you want something in this vein, we have splatting which works:

$rf = @{ Recurse = $true; Force = $true }

Remove-Item -Path $folder @rf

[rjmholt]

this works in gnu land because single hyphen parameters are guaranteed to be one letter in length

I'm not sure such things are more than just conventional between commands (the convention existing because of a shared dependency on getopt) and I can think of a few counter examples:

• ls -al
• rm -rf
• tar -xvf
• xclip -selection c
• find -printf

In powershell, we don't have that safety

I would contend that PowerShell's cmdlets have their parameter syntax much more rigorously enforced.

But to the point of shadowing parameters and unpredictability, I've seen that raised in other scenarios but my feeling is that PowerShell, as a shell and scripting language, embraces dynamism. There are plenty of things you can do today that are state driven and could be classed as unpredictable. Certainly a huge number of core PowerShell behaviours are things that can't be promised before runtime (working on PowerShell Editor Services and PSScriptAnalyzer has bourne this out for me). If it's possible to override a command (function Remove-Item { param($Path) Write-Host "Didn't remove $Path" }), then I think we need better reasons why it shouldn't be possible for parameters.

The heart of this proposal is I think to find a PowerShell way to express a sh alias like alias ll='ls -l' or a way to condense common parameter combinations for muscle memory purposes, and splatting doesn't accomplish that because it's not pithy enough and relies on local state.

[joeyaiello]

In my mind, this scenario is primarily around interactive, muscle-memory usage. I don't see it as any less PS-y than, say, using rm instead of Remove-Item from the command line. We've always agreed that pithy usage is beneficial, just not in well-maintained automation artifacts.

To be clear, I'm not in favor of shipping any of these by default today. This would be something the user would want to define. But I've always thought it would be cool to have some sort of "I'm used to Bash" module that serves as a collection of aliases and behaviors like this (akin to #5870).

But bias on the table: this is something I've wanted for a very long time almost solely so I can type rm -rf on Windows without removing the alias and overriding rm with a function.

[rjmholt]

To be clear, I'm not in favor of shipping any of these by default today

100% agreed there

[iSazonov]

To be clear, I'm not in favor of shipping any of these by default today. This would be something the user would want to define. But I've always thought it would be cool to have some sort of "I'm used to Bash" module that serves as a collection of aliases and behaviors like this (akin to #5870).

https://github.com/PowerShell/PowerShell-RFC/pull/129