Simplify Creating Items with PowerShell Providers

Simplify Creating Items with PowerShell Providers

  • Comments 3
  • Likes

Summary: Learn how to use the same syntax to create different types of items via Windows PowerShell providers.

 

Hey, Scripting Guy! QuestionHey, Scripting Guy! I am wondering about the Windows PowerShell idea of providers. I have seen you mention them before, but not recently. I am not even sure that the Scripting Wife has talked about Windows PowerShell providers. Is this something that is not very important? Have you just overlooked something? What is the deal?

—GB
 

Hey, Scripting Guy! AnswerHello GB,

Microsoft Scripting Guy Ed Wilson here. This week I am onsite with customers talking to them about Windows PowerShell. In fact, I had a number of questions about providers today, so the ideas are fresh in my mind. I cannot check to see how many articles I have actually mentioned Windows PowerShell providers, because the search is not working very well on the Hey, Scripting Guy! Blog right now. We are in the process of transitioning to a new mechanism, and it is busy rebuilding new indexes.

The topic of providers has not been overlooked, but maybe just not highlighted too much. For example, in getting ready for the 2010 Scripting Games, the Scripting Wife had a lesson using the registry provider.

The cool thing about Windows PowerShell providers is they provide a single way to access different types of data. For example, the provider cmdlets all have the word Item in the noun (either in part or completely). These cmdlets are shown here:

PS C:\> Get-Command -Noun *item* | Select-Object name

 

Name

Clear-Item

Clear-ItemProperty

Copy-Item

Copy-ItemProperty

Get-ChildItem

Get-Item

Get-ItemProperty

Invoke-Item

Move-Item

Move-ItemProperty

New-Item

New-ItemProperty

Remove-Item

Remove-ItemProperty

Rename-Item

Rename-ItemProperty

Set-Item

Set-ItemProperty

The reason they use the word Item is because they can work against different data sources, so they could be one of many different types of items. For example, if I am on my C:\ drive, and I use the New-Item cmdlet, I can create either a new file or folder. This command will use the filesystem provider. I must tell the provider what I want to create: either a file or folder. This is shown here:

PS C:\> New-Item -Name example1 -Path c: -ItemType directory

    Directory: Microsoft.PowerShell.Core\FileSystem::C:\

Mode               LastWriteTime                            Length Name

d----                 9/27/2011  8:51 PM                    <DIR> example1 

 

PS C:\> New-Item -Name example.txt -Path C:\example1 -ItemType file

    Directory: Microsoft.PowerShell.Core\FileSystem::C:\example1

Mode               LastWriteTime                Length Name

-a---                 9/27/2011  8:52 PM        0 example.txt

 

If I change to the variable drive and use the New-Item cmdlet, I will create a new variable. Only one type of item exists on a variable drive (a variable), so there is no need to use the itemtype parameter with the command. This technique is shown here where I use the New-Item cmdlet to create a new variable. I then call the variable to illustrate that it is created, and that it contains the string value “example variable.”

PS C:\> Set-Location variable:

PS Variable:\> New-Item -Name example -Value "example variable"

 

Name                           Value

Example                        example variable

 

PS Variable:\> $example

example variable

PS Variable:\>

 

When I change my working drive to the env (environmental variable drive) drive, the exact same command I used to create an example variable creates an example environmental variable. In the following code, I first change my working drive to the env: drive. Next, I create an environmental variable named example, and I assign the string value “example variable” to this environmental variable. I then retrieve the value of the new environmental variable by accessing it from the $env: drive. This code is shown here:

PS Variable:\> Set-Location env:

PS Env:\> New-Item -Name example -Value "example variable"

 

Name               Value

Example            example variable 

 

PS Env:\> $env:example

example variable

PS Env:\>

Once again, I use the Set-Location cmdlet to change to a new drive. This time, it is the alias: drive. I again use the New-Item cmdlet in exactly the same way I used it earlier: to create a new alias for the Get-PSDrive cmdlet. To create the new alias, I give it a name, psd, and I assign a value, Get-PSDrive. The command and associated output are shown here:

PS Env:\> Set-Location alias:

PS Alias:\> New-Item -Name psd -Value Get-PSDrive

 

CommandType              Name               Definition

Alias                              psd                   Get-PSDrive

To see if the new alias works, I type psd on the Windows PowerShell console. The output is shown here:

PS Alias:\> psd

 

Name               Used (GB)          Free (GB)           Provider                        Root

Alias                                                                  Alias

C                      99.85                47.66                FileSystem                     C:\

Cert                                                                  Certificate                      \

D                                                                      FileSystem                     D:\

E                                                                      FileSystem                     E:\

Env                                                                   Environment

Feed                                                                 FeedStore

Function                                                            Function

Gac                                                                   AssemblyCache              Gac

HKCU                                                                Registry                         HKEY_CURRENT_USER

HKLM                                                               Registry                         HKEY_LOCAL_MACHINE

Pscx                                                                  PscxSettings

Variable                                                                        Variable

WSMan                                                             WSMan

I can even use the function drive to create a new function. This is COOL! In the following example, I create a new function that returns information about the winword process (the process name used by Microsoft Word). Normally, I would need to write the function as is shown here:

Function get-word

{

 Get-process winword

}

The key items to creating the function are the function keyword, the name of the function (get-word), the script block {}, and the code itself: Get-process winword.

As shown in the code that follows, by using the function drive and the New-Item cmdlet, I leave off the braces that mark the script block and the function keyword:

PS Alias:\> sl function:

PS Function:\> New-Item -Name get-word -Value "get-process winword"

 

CommandType              Name                           Definition

Function                        get-word                       get-process winword

But does the new Get-Word function actually work? As shown here, it does work:

PS Function:\> get-word

 

Handles             NPM(K)             PM(K)   WS(K)   VM(M)  CPU(s)               Id         ProcessName

746                   74                     37872   87000   404       31.72                1280     WINWORD

If I pop over to the HKCU registry drive, I can even use the New-Item cmdlet to create a new registry key:

PS Function:\> Set-Location hkcu:

PS HKCU:\> New-Item -Path HKCU:\Software -Name example

    Hive: HKEY_CURRENT_USER\Software

SKC      VC        Name               Property

0          0          example            {}

 

So, GB, I hope this quick tour of the various Windows PowerShell drives that the Windows PowerShell providers create will inspire you to experiment with this powerful tool. The really revolutionary thing is using exactly the same command—and in any case the same syntax—to create a new alias, file, folder, variable, environmental variable, function, and registry key. Exploring the Windows PowerShell provider subsystem will pay great dividends.

 

Tomorrow, I will continue talking about Windows PowerShell providers.

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

Ed Wilson, Microsoft Scripting Guy

 

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi Ed,

    the powershell provider system is really a great deal!

    But it is something that is so different from the traditional approaches that use seperate commands to navigate each "subsystem". It is really hard for somebody like me to deal with these more abstract "items" and to remember if I have to use e.g. the "itemType" parameter which is sometimes required and sometimes not.

    In fact I have to know the underlying provider in order to be able to supply parameters that are meaningful to it. And I sometimes get lost in the world of "Items" and "ItemProperties" ( especially if the provider is the registry)

    I still can live with commands like "set", "md", "rd" ...

    So ... it may take some time to get used to the new ( and it is excellent for sure ) provider system ...

    Klaus.

  • @Klaus you are right. The PowerShell provider system is really cool, and it does take some getting used to. Keep in mind, that when creating aliases, or variables, we DO have additional cmdlets with parameters that are more customized to the specific provider. For me, because I understand the underlying provider, I enjoy the ability to use the more generic cmdlets. When working with the Registry, I love using the item and itemproperty cmdlets ... but I know some people who find the concepts so foreign, they resort to using .NET framework cmdlets, VBScript type COM objects, or even WMI classes. This is a shame, because in each case the orders of complexity increase.

  • So glad to see this post, because it tickles a pet peeve of mine with PowerShell.  New-Item takes an ItemType parameter, which identifies what kind of thing you want the provider to create.  But it seems like you are at the mercy of the docmentation for that provider to tell you what the list of allowed ItemTypes may be.  If that documentation is incomplete or difficult to locate, you're stuck.  Can we hope that there will ever be support for some way to ask a PSProvider to identify what item types it's designed to create?