How to "alias" with a bound parameter without breaking pipelining in Powershell? - powershell

Question

I find myself often tacking |select -first 10 onto the end of commands, and I'd like to shorten that to |s10, |s50, and a couple other variants. So I'd like to do the equivalent of set-alias s10 select-object -first 10.
The standard way you "alias" with bound parameters is to write a function and forward #args along with the extra params. But if I write a function that pipes $input through select-object, I lose streaming.
I could write a begin/process/end function, but I don't know if/how I can forward each of those to equivalents in select-object. I could write my own begin/process/end implementation of select-object that just implements the -first behavior, but that's just wrong...
(My fallback is to add a tab-completion to expand s10, but I'd really rather learn how I can implement a proper function.)
How can I implement a function that forwards to select-object with a parameter I want added but doesn't break pipelining?

Answer 1

I found this source https://blogs.technet.microsoft.com/heyscriptingguy/2011/03/01/proxy-functions-spice-up-your-powershell-core-cmdlets/
In this case, a shortcut/alias for Select-String -First 10, it comes down to:
$metadata = New-Object System.Management.Automation.CommandMetaData (Get-Command Select-Object)
[System.Management.Automation.ProxyCommand]::Create($MetaData) | Out-File -FilePath prxyfunctions.psm1
Open the prxyfunctions.psm1 module file and wrap the complete content in the new function called S10
function S10 {
[CmdletBinding(DefaultParameterSetName = 'DefaultParameter', HelpUri = 'https://go.microsoft.com/fwlink/?LinkID=113387', RemotingCapability = 'None')]
param(
<abbreviated...>
.ForwardHelpTargetName Microsoft.PowerShell.Utility\Select-Object
.ForwardHelpCategory Cmdlet
#>
}
Then in the Begin{} section add one statement $PSBoundParameters.Add('First','10') like below.
begin {
try {
$outBuffer = $null
if ($PSBoundParameters.TryGetValue('OutBuffer', [ref]$outBuffer)) {
$PSBoundParameters['OutBuffer'] = 1
}
$PSBoundParameters.Add('First','10')
$wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Microsoft.PowerShell.Utility\Select-Object', [System.Management.Automation.CommandTypes]::Cmdlet)
$scriptCmd = {& $wrappedCmd #PSBoundParameters }
$steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
$steppablePipeline.Begin($PSCmdlet)
}
catch {
throw
}
}
That's it. Save the file, import the module, type a nice short command like gci c:\|s10 and get just 10 results.
If you really want to make things error proof, more coding is needed. If S10 -First 2 is used you'll get a nice error thrown.
EDIT in response to #PetSerAl 's useful comments
Some cmdlets further in the pipeline might not be able to handle the proxied function, for instance Sort-Object. Compare the output of these two lines
-join (20..1 | Select -First 10 | Sort)
11121314151617181920
-join (20..1 | S10 | Sort)
<nothing>
-join (20..1 | S10 -Wait | Sort)
11121314151617181920
It is possible to work around that by using the -Wait parameter on the commandline. Or code the Wait parameter in the proxy function $PSBoundParameters.Add('Wait',$true)
When working with large collections this is unfortunate because it disables the Select-Object feature that stops the pipeline after x elements, resulting in more processing and longer waiting.

Answer 2

never use aliases in production scripts is what I would say (and is considered best practice). If its a bit of test code or something quick and dirty that no-one else will ever use, fair enough, but never in production scripts. Aliases can be removed, changed to run other commands and leave you with unintended results as they are user specific.