Cmdlet clashes

One of the things that struck me whilst developing Grrr as a snapin is: what do you do when you have a cmdlet with the same verb-noun pair as an existing cmdlet?

If someone else had a cmdlet called, say, out-banner, and that cmdlet was already loaded in a snap-in (perhaps mandated by site policy), would I be able to register and add the Grrr snapin, which also defines it?

I’ve scanned the available documentation and the language grammar, used introspection in the shell and so on, but could not find anything to deal with this problem.

With projects like PowerShell Community Extensions seemingly laying claim to hundreds of common nouns and verbs, I was concerned that the scope for writing unique cmdlets would dry up real fast.

To determine what would happen, I registered and added Soapyfrog.Grrr, then wrote a new snapin, Soapyfrog.Conflict, with a single cmdlet, out-banner, conflicting with the one in Grrr.

I registered and added this, and was surprised that no warning of a conflict was given. To see if both were added, I tried this:

PS> get-command out-banner

CommandType     Name                        Definition
-----------     ----                        ----------
Cmdlet          Out-Banner                  Out-Banner [-Text] <Str...
Cmdlet          Out-Banner                  Out-Banner [-Text] <Str...

Interesting. Both are available, so what happens when I try to invoke it?

PS> out-banner hello
The term 'out-banner' resolved to a cmdlet name that is ambiguous. Pos
sible matches include: Soapyfrog.Grrr\Out-Banner soapyfrog.conflict\Ou
t-Banner.
At line:1 char:11
+ out-banner  <<<< hello

OK, so at this point, we know it’s possible to break existing PowerShell scripts by simply registering and adding a new snapin with a same-named cmdlet. Not good. Is there a work-around?

PS> Soapyfrog.Grrr\out-banner hello -fg 'o'
o   o ooooo o     o      ooo
o   o o     o     o     o   o
ooooo ooo   o     o     o   o
o   o o     o     o     o   o
o   o ooooo ooooo ooooo  ooo

Yes! We can fully qualify the cmdlet name with the snapin name and a backslash.

So, it’s not as bad as I first feared, but as I noted above, you need to be very careful about how you code and run scripts in environments where you can’t predict what snapins are registered and installed.

I suppose you can create the correct shell environment with Export-Console and run your script with:

powershell -psconsolefile xxx.psc1 -noprofile -command myscript.ps1

Or if your script requires a snapin, add the snapin in the script and fully qualify each cmdlet you use.