|
Bug? Shouldn't Stop-Process automatically match Id if object is a process?
Although you can pipe a process into Stop-Process, or specify it as an
InputObject value, if you supply the process as a default value, it fails
abysmally. For example:
PS> calc;$calc = gps -Name calc
PS> spps -InputObject $calc
PS> calc;$calc = gps -Name calc
PS> spps $calc
Stop-Process : Cannot bind parameter 'Id'. Cannot convert "System.Diag
nostics.Process (calc)" to "System.Int32".
At line:1 char:5
+ spps <<<< $calc
Obviously this is because a System.Diagnostics.Process is not an Int32.
Almost as obviously, if we could do this, it would in some ways make the
InputObject not very useful and could arguably blur the distinction of Id.
Still, if someone is specifying a process reference, it very clearly is a
uniquely identified process which has an Id that can be determined.
Therefore, it should be possible to for that special case simply resolve the
item to an Id. Is this possible to do without making the Id surfacing too
complex? And if so, is there a reason why it might be harmful to allow?
|