Dealing with Cmdlet Name Conflicts

What would happen if you attempted to load a module that contained a function named Get-ChildItem? Keep in mind that Get-ChildItem is a core PowerShell cmdlet, so it already exists. When I ran Get-ChildItem, the function, rather than the built-in command, would run. I could still access the built-in command like this:

microsoft.powershell.managementget-childitem

That's pretty awkward, but there's actually a very cool reason for this: It means I can "overwrite" PowerShell's own core functionality. In a future article, I'll write about "proxy functions," which can do some pretty amazing stuff.

This business with name conflicts is one reason you'll usually see cmdlet authors add a short prefix to the noun portion of their cmdlet name. You don't get "Get-User," you get "Get-ADUser," tying the cmdlet to a specific technology (AD) and helping to avoid conflicts with other "user" related cmdlets that you might need to load into the shell.

Want to ask a question about this article? I'll answer at http://powershell.com/cs/forums/230.aspx!