Summary<\/b>: Microsoft Scripting Guy, Ed Wilson, explores Windows PowerShell profiles and locations.\nMicrosoft 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.\nSince Windows PowerShell 1.0 came out, the $profile<\/b> 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:<\/p>\n
PS C:> $PROFILE<\/p>\n
C:UsersedDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1<\/p>\n
PS C:>\nSee what I mean? Dude. That is a lot of typing. But I do not have to type any of that, because $profile<\/b> 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!\nBut 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<\/a>. 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<\/a>.<\/p>\n 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?”\nWell, it must be to list out the profile paths, and use Test-Path<\/b>. If I use Get-Member<\/b> to list the note properties, and use Force<\/b> to show hidden properties, I can find the names of the profiles, in additon to the path.\nThe problem is that to get the path, I would have to use a regular expression to parse the string. This is because $profile<\/b> returns a string, and the extra profiles are added in as note properties. This is shown here:<\/p>\n PS C:> $PROFILE | gm -MemberType NoteProperty -Force<\/p>\n TypeName: System.String<\/p>\n Name MemberType Definition<\/p>\n —- ———- ———-<\/p>\n AllUsersAllHosts NoteProperty System.String AllUsersAllHosts=C:WindowsSystem32WindowsPowerShellv1.0profil…<\/p>\n AllUsersCurrentHost NoteProperty System.String AllUsersCurrentHost=C:WindowsSystem32WindowsPowerShellv1.0Mic…<\/p>\n CurrentUserAllHosts NoteProperty System.String CurrentUserAllHosts=C:UsersedDocumentsWindowsPowerShellprofil…<\/p>\n CurrentUserCurrentHost NoteProperty System.String CurrentUserCurrentHost=C:UsersedDocumentsWindowsPowerShellMic…\nI 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<\/strong> and calling it by name. This is shown here:<\/p>\n PS C:> $PROFILE.AllUsersAllHosts<\/p>\n C:WindowsSystem32WindowsPowerShellv1.0profile.ps1\nHmmm, so I need to store the profile names in an array, and walk through them after I append them to $profile<\/b>. First I get the profile names and store them in an array, as shown here:<\/p>\n $p = $PROFILE | gm -MemberType NoteProperty -Force | % {$_.name}\nI now check to see if it worked:<\/p>\n PS C:> $p[0]<\/p>\n AllUsersAllHosts\nYep. So far so good. Now, I decide to walk through the array:<\/p>\n PS C:> $p | foreach {$PROFILE.$_}<\/p>\n C:WindowsSystem32WindowsPowerShellv1.0profile.ps1<\/p>\n C:WindowsSystem32WindowsPowerShellv1.0Microsoft.PowerShell_profile.ps1<\/p>\n C:UsersedDocumentsWindowsPowerShellprofile.ps1<\/p>\n C:UsersedDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1\nOK. Now I need to find out which profiles exist. I use the Test-Path<\/strong> cmdlet to do this. Here is the command:<\/p>\n PS C:> $p | foreach {$PROFILE.$_ ; Test-Path $profile.$_}<\/p>\n C:WindowsSystem32WindowsPowerShellv1.0profile.ps1<\/p>\n False<\/p>\n C:WindowsSystem32WindowsPowerShellv1.0Microsoft.PowerShell_profile.ps1<\/p>\n False<\/p>\n C:UsersedDocumentsWindowsPowerShellprofile.ps1<\/p>\n False<\/p>\n C:UsersedDocumentsWindowsPowerShellMicrosoft.PowerShell_profile.ps1<\/p>\n True\nI 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.\nI 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.\nEd Wilson, Microsoft Scripting Guy<\/b> <\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/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":[144,3,4,61,45],"class_list":["post-977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-profiles","tag-scripting-guy","tag-scripting-techniques","tag-weekend-scripter","tag-windows-powershell"],"acf":[],"blog_post_summary":" 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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/977","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=977"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/977\/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=977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Does a profile exist?<\/h2>\n