I’ve been playing with get-printjob and am confused about using a positional parameter.
You can see a printer’s print job by typing “get-printjob” followed by either the printer’s name (a string) or a printer object (probably something like “$p,” assuming that I’ve done something like $p=get-printer… or the like. I understand the two parameter sets (in one, “1” means “-printername,” in the other, “1” means "-printerobject." But here’s what’s hanging me up.
If I have a printer named “Epson MX80” and I just type
get-printjob “Epson MX80”
Then I get “A parameter cannot be found that matches parameter name ‘name’.”
Now, if I type
get-printjob “-printername Epson MX80”
Then all is well. Furthermore, if I type print-job followed by the names of any drivers that I’ve got loaded but that have no actual printers associated with them, all’s well.
It looks to me as if the problem with typing get-printjob followed by a string is somehow confusing the PowerShell parser. I’d think that if I pass get-printjob a simple string then I GET that PoSH has to figure out if I’m asking for the -printername parameter set or the -printobject parameter set, but honestly that seems like a pretty easy question, no?
So my question is… I’ve got a cmdlet with two parameter sets. There is a positional parameter “1” that, once understood, kicks it into the first or second parameter set. It’s getting confused. Is there some way to help it, like
get-printjob [string]:“Epson MX80”
(I know, that syntax doesn’t exist) or something like that?
So, Get-PrintJob is one of the new CIM cmdlets, meaning is was kinda auto-generated-ish based on the MOF class. Just trivia.
It does look like -PrinterName is in position 1 if you use a System.String; if you use an object of type CimInstance in position 1, it goes to -PrinterObject. So it’s kinda like an overload in .NET. It picks the parameter set based on the data type.
If get-printjob “Epson MX80″ doesn’t work, and is complaining about -Name, it sounds like a bug, frankly. Fortunately, we have troubleshooting mojo to play with.
The resulting yellow spew shows me it’s binding the string to -PrinterName. Successfully, too, passing some validation checks and a data conversion. But then it tries to also bind it to -PrinterObject… which fails, so it skips it. It appears to move on and bind everything else successfully (meaning giving them nothing).
It’s actually making a little fake object under the hood - you’ll see a ton of work going on with New-Object. It must be doing that to create the output object, because Out-Default gets bound next. Mind you, all this happens before anything executes much.
But for me, with a valid printer name, it appears to be working. You’re gonna have to spelunk this on your system to see what it does. Feel free to attach a transcript with all the debugging spew, if you want.
[string]“this” will do a cast, as will (“this” -as [string]) if you need that.
Thanks! (Hotmail stuffed this in Junk so I hadn’t seen it before.) Much appreciated. It’s so nice to know that the trace tool that we’re not just feeling around in the dark trying to figure out what a cmdlet’s doing.
See you at whatever the next show is, Don. I appreciate the answer.