Weekend Scripter: Exploring Powershell Profiles

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, explores Windows PowerShell profiles and locations. Microsoft Scripting Guy, Ed Wilson, is here. One of the cool things about the weekend is that it provides two entire days with no meetings, no specific obligations, and it gives me time to think and reflect. This is also a time to play with Windows PowerShell. Since Windows PowerShell 1.0 came out, the $profile automatic variable points to the CurrerentUserCurrentHost Windows PowerShell profile. This is extremely helpful because otherwise it would be a heck of a lot of typing, even when using tab expansion. Here is an example:

PS C:> $PROFILE

C:UsersedDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1

PS C:> See what I mean? Dude. That is a lot of typing. But I do not have to type any of that, because $profile points to the location. The really cool thing is that it points to that location even if I do not have a profile. That is sweet! But Windows PowerShell has more than one profile. In fact, there are six when one takes into account the Windows PowerShell console and the Windows PowerShell ISE. For more information, see Understanding the Six PowerShell Profiles. I have also written about the profiles, using them, and best practices for managing them. To read more about profiles, see these Hey, Scripting Guy! Blog posts.

Does a profile exist?

I ran into an issue the other day, in that Windows PowerShell was acting a bit funky. I looked in my Windows PowerShell console profile, but I did not see anything wrong. I thought, “Hmmmm. I must have added something somewhere else. But what is the easiest way to see if a profile exists?” Well, it must be to list out the profile paths, and use Test-Path. If I use Get-Member to list the note properties, and use Force to show hidden properties, I can find the names of the profiles, in additon to the path. The problem is that to get the path, I would have to use a regular expression to parse the string. This is because $profile returns a string, and the extra profiles are added in as note properties. This is shown here:

PS C:> $PROFILE | gm -MemberType NoteProperty -Force

   TypeName: System.String

Name                   MemberType   Definition

—-                   ———-   ———-

AllUsersAllHosts       NoteProperty System.String AllUsersAllHosts=C:WindowsSystem32WindowsPowerShellv1.0profil…

AllUsersCurrentHost    NoteProperty System.String AllUsersCurrentHost=C:WindowsSystem32WindowsPowerShellv1.0Mic…

CurrentUserAllHosts    NoteProperty System.String CurrentUserAllHosts=C:UsersedDocumentsWindowsPowerShellprofil…

CurrentUserCurrentHost NoteProperty System.String CurrentUserCurrentHost=C:UsersedDocumentsWindowsPowerShellMic… I do not like to parse strings with regular expressions if I don’t have to do so. And I know that I can find a specific path to a specific profile by adding a dot to the end of $profile and calling it by name. This is shown here:

PS C:> $PROFILE.AllUsersAllHosts

C:WindowsSystem32WindowsPowerShellv1.0profile.ps1 Hmmm, so I need to store the profile names in an array, and walk through them after I append them to $profile. First I get the profile names and store them in an array, as shown here:

$p = $PROFILE | gm -MemberType NoteProperty -Force | % {$_.name} I now check to see if it worked:

PS C:> $p[0]

AllUsersAllHosts Yep. So far so good. Now, I decide to walk through the array:

PS C:> $p | foreach {$PROFILE.$_}

C:WindowsSystem32WindowsPowerShellv1.0profile.ps1

C:WindowsSystem32WindowsPowerShellv1.0Microsoft.PowerShell_profile.ps1

C:UsersedDocumentsWindowsPowerShellprofile.ps1

C:UsersedDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1 OK. Now I need to find out which profiles exist. I use the Test-Path cmdlet to do this. Here is the command:

PS C:> $p | foreach {$PROFILE.$_ ; Test-Path $profile.$_}

C:WindowsSystem32WindowsPowerShellv1.0profile.ps1

False

C:WindowsSystem32WindowsPowerShellv1.0Microsoft.PowerShell_profile.ps1

False

C:UsersedDocumentsWindowsPowerShellprofile.ps1

False

C:UsersedDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1

True I can see that, in fact, I only have one profile for my Windows PowerShell console. There are still two other profiles that I need to check via the Windows PowerShell ISE. But because my issue was in the console, I need to go into the various modules that I use. Anyway, now I have a starting point. See you tomorrow. 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 

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow