Coping with a PowerShell naming clash

Naming clashes are something I expect to increase in frequency when PowerShell starts to be used more widely. I thought I would show you how to solve some categories of naming clashes. I will deal here with some of the situations that can arise when naming functions using names similar to cmdlets, that is verb-noun.

The situation can, potentially, become really complex so I will deal in this post only with some simple situations.

The name of a function can clash with an existing alias or cmdlet name. As an example consider what happens if you have written a function called rename-item. If you've been reading recent posts on this blog you will know that PowerShell has a rename-item cmdlet.

Assume that you have opened a fresh PowerShell console window.

If you type rename-item at the command line then you see a prompt

PS C:\> rename-item

cmdlet rename-item at command pipeline position 1
Supply values for the following parameters:
Path:

PowerShell prompts you to supply a value for the Path parameter.

Press Ctrl+C to stop this.

At the command line type the following to create the rename-item function:

function rename-item{

write-host "This output is from the rename-item function"

}

Then type at the command line:

rename-item

You will see an appearance like this:

PS C:\> rename-item
This output is from the rename-item function
PS C:\>

By creating a function called rename-item you have, effectively, blocked execution of the rename-item cmdlet at the command line.

Why does this happen? PowerShell attempts to find an executable to match a command in the following order:

1. Aliases
2. Functions
3. Cmdlets
4. Executables
5. Scripts
6. Normal files

So when you created the rename-item function it takes precedence over the rename-item cmdlet.

If you want to be sure to have access to the rename-item cmdlet avoid creating a global function with that name since the function will always have higher priority than the cmdlet.