)<\/span> <\/p>\n <\/p>\n
Note the first thing we do is remove our parameter from PSBoundParameters. If we don\u2019t do that, the real cmdlet Get-ChildItem will complain about the unknown parameter when it is specified.<\/p>\n
I wanted functionality and syntax as close to cmd.exe as possible. So we should support things like \u2018dir \u2013a:h-sr\u2019, which would include hidden read-only files that are not system files. To do this, I generate bitmasks representing the attributes requested, then filter the output of the actual Get-ChildItem command based on these bitmasks.<\/p>\n
Note the script block assigned to $scriptCmd is similar to the one generated by ProxyCommand.Create, but it includes some filtering. Steppable pipelines can\u2019t be created for arbitrary script blocks, only when there is a single pipeline in the script block. Fortunately we can do all our filtering in one pipeline.<\/p>\n
If you wanted to add sorting to the output, you could extend this pipeline to do the appropriate sorting. I leave it as an exercise for the reader to add the cmd.exe sorting flags like \/OD, \/O-D, \/OS, \/O-S, etc.<\/p>\n
ProxyCommand.Create works pretty good, but it doesn\u2019t generate code to support dynamic parameters. Most cmdlets don\u2019t have dynamic parameters, but Get-ChildItem definitely does, so we want our proxy to support them as well. Different providers can add dynamic parameters to Get-ChildItem, so the optimal solution is to, at runtime, ask the Get-ChildItem cmdlet what dynamic parameters it has. We can do that this way:<\/p>\n
[void]<\/span>$PSBoundParameters<\/span>.<\/span>Remove<\/span>(<\/span>'Attribute'<\/span>)<\/span>\n$argList<\/span> =<\/span> @(<\/span>$psboundparameters<\/span>.<\/span>getenumerator<\/span>(<\/span>)<\/span> |<\/span> %<\/span> {<\/span> \"-$($_.Key)\"<\/span>;<\/span> $_<\/span>.<\/span>