{"id":739,"date":"2014-09-04T00:01:00","date_gmt":"2014-09-04T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2014\/09\/04\/powershell-naming-conflicts\/"},"modified":"2014-09-04T00:01:00","modified_gmt":"2014-09-04T00:01:00","slug":"powershell-naming-conflicts","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/powershell-naming-conflicts\/","title":{"rendered":"PowerShell Naming Conflicts"},"content":{"rendered":"

Summary<\/b>: Learn how to handle naming conflicts for Windows PowerShell cmdlets.<\/span><\/p>\n

\"Hey, Hey, Scripting Guy! My Windows PowerShell installation is completely hosted on my laptop. In fact, I tried to uninstall and reinstall Windows PowerShell, but that did not work. I really do not want to have to pave my laptop. I download this module from the Internet. It works really well, but the issue is that one of the cmdlets replaced one of the standard cmdlets on my computer. I really need to be able to use the standard cmdlet, and I do not know what to do. Help!<\/p>\n

—DV<\/p>\n

\"Hey, Hello DV,<\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. This morning I am sitting at my desk sipping a cup of English Breakfast tea with a bit of licorice root, peppermint herb, spearmint herb, and a cinnamon stick. It is quite refreshing, and delightful—especially because my arms feel like they are made from rubber. I just got back from the gym. (It is difficult to replace years of bad habits with a few weekly sessions at the gym, but it is also import to get started—and that is what I am doing.)<\/p>\n

PowerShell cmdlet naming conflicts<\/h2>\n

Windows PowerShell is powerful and easy-to-use. It makes a lot of decisions for me. For example, if I import a module that has a cmdlet with the same name as an existing cmdlet, Windows PowerShell will use the new cmdlet. For example, let's say that I import a module named Process<\/b>. <\/i>It has a function named Get-Process<\/b>. When I type Get-Process<\/b>, I get the results from that function. This is shown here:<\/p>\n

\"Image<\/a><\/p>\n

From this display, I see that I am not getting the normal output from the Get-Process<\/b> cmdlet that I have used since Windows PowerShell 1.0 came out. This is disappointing. So I use the Get-Command<\/b> cmdlet to see what is going on. Here are the results:<\/p>\n

PS C:\\> Get-Command -Module Process<\/p>\n

CommandType     Name                                               ModuleName<\/p>\n

———–     —-                                               ———-<\/p>\n

Function        Get-Process                                        Process<\/p>\n

It seems that Get-Process<\/b> has been replaced by a function with the same name. It is from a module named Process<\/b>. <\/i><\/p>\n

I can unload that module by using the Remove-Module<\/b> cmdlet as shown here:<\/p>\n

Remove-Module Process<\/p>\n

   Note<\/b>  Using Remove-Module<\/b> only unloads the module from memory. It does not actually delete the module, nor does
   it remove it from disk.<\/p>\n

Now if I use the Get-Process<\/b> cmdlet, I see the standard output. This is shown here:<\/p>\n

\"Image<\/a><\/p>\n

But what if I want the commands that are available from the Process<\/b> <\/i>module? How can I have access to those commands, and also access the standard Get-Process<\/b> cmdlet? There are actually two ways to coexist…<\/p>\n

Two ways to coexist<\/h2>\n

The first way to coexist (but by no means the easiest) is to reference the cmdlet by its complete name. This is the name of the module, separated by a backslash, and then the cmdlet name. To determine the cmdlet’s module, use the Get-Command<\/b> cmdlet. Here is an example:<\/p>\n

PS C:\\> Get-Command Get-Process | ft -AutoSize<\/p>\n

CommandType Name        ModuleName<\/p>\n

———– —-        ———-<\/p>\n

Cmdlet      Get-Process Microsoft.PowerShell.Management<\/p>\n

I see that the Get-Process<\/b> cmdlet is in the Microsoft.PowerShell.Management module, so this is what I will need to type.<\/p>\n

I import the Process<\/b> <\/i>module, check to ensure that the Get-Process<\/b> cmdlet is overwritten, and then specify the complete name. It works:<\/p>\n

PS C:\\> Import-Module Process<\/p>\n

PS C:\\> Get-Process | select -Last 1<\/p>\n

splwow64.exe<\/p>\n

PS C:\\> Microsoft.PowerShell.Management\\Get-Process | select -Last 1<\/p>\n

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName<\/p>\n

——-  ——    —–      —– —–   ——     — ———–<\/p>\n

   1630     142   112116     154792   530    10.41   7044 WWAHost<\/p>\n

   Note <\/b> Tab expansion does not work for module names when you are specifying the complete name. So it is helpful to
   copy the module name to the Clipboard when looking it up via Get-Command<\/b>.<\/p>\n

The second way to coexist is to specify a command prefix when you import the module. This will add a couple of letters to the noun name; therefore, it avoids the naming conflict. Here is an example:<\/p>\n

First I import the module, and specify the prefix. Then I use Get-Command<\/b> to see the cmdlet name, and I use the new cmdlet name (Get-edProcess<\/b>) to retrieve a single process name. This is shown here:<\/p>\n

PS C:\\> Import-Module Process -Prefix ed<\/p>\n

PS C:\\> Get-Command -Module process<\/p>\n

CommandType     Name                                               ModuleName<\/p>\n

———–     —-                                               ———-<\/p>\n

Function        Get-edProcess                                      Process<\/p>\n

PS C:\\> Get-edProcess | select -Last 1<\/p>\n

splwow64.exe<\/p>\n

Now I can use the standard cmdlet with the standard cmdlet name. Here, I retrieve a single process object:<\/p>\n

PS C:\\> Get-Process | select -Last 1<\/p>\n

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName<\/p>\n

——-  ——    —–      —– —–   ——     — ———–<\/p>\n

   1630     142   112116     154304   530    10.41   7044 WWAHost<\/p>\n

DV, that is all there is to handling Windows PowerShell naming conflicts. Join me tomorrow when I will talk about the Windows PowerShell Summit in Amsterdam.<\/p>\n

I invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.<\/p>\n

Ed Wilson, Microsoft Scripting Guy<\/b><\/p>\n","protected":false},"excerpt":{"rendered":"

Summary: Learn how to handle naming conflicts for Windows PowerShell cmdlets.  Hey, Scripting Guy! My Windows PowerShell installation is completely hosted on my laptop. In fact, I tried to uninstall and reinstall Windows PowerShell, but that did not work. I really do not want to have to pave my laptop. I download this module from […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[51,3,4,45],"class_list":["post-739","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-getting-started","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

Summary: Learn how to handle naming conflicts for Windows PowerShell cmdlets.  Hey, Scripting Guy! My Windows PowerShell installation is completely hosted on my laptop. In fact, I tried to uninstall and reinstall Windows PowerShell, but that did not work. I really do not want to have to pave my laptop. I download this module from […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/739","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=739"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/739\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=739"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=739"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=739"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}