Podczas pracy z sesją PowerShell można modyfikować jej stan (lub środowisko) na dowolną liczbę sposobów: Możesz importować moduły, tworzyć funkcje, określać aliasy lub definiować zmienne, by wymienić tylko kilka z nich. Wszystkie te czynności są jednak przejściowe: ich efekty znikają, gdy tylko zamkniemy sesję PowerShell. PowerShell dostarcza jednak mechanizm, zwany profilem PowerShell, który pozwala odtworzyć wszystkie takie konstrukcje i ustawienia środowiska za każdym razem, gdy uruchamiamy nową sesję PowerShell. A skoro jeden profil jest dobry, to czy nie lepiej byłoby mieć ich więcej? Okazuje się, że każda pojedyncza sesja PowerShell może używać jednego (lub wszystkich) z czterech różnych profili, a różne hosty PowerShell zapewniają jeszcze więcej możliwości wyboru profili: Ale w rzeczywistości jest to znacznie prostsze w użyciu, niż to wszystko może się wydawać, gdy docenisz, gdzie wszystkie ruchome części pasują. Przyjrzyjmy się temu.
Powłoka w PowerShell
W PowerShell istnieje rozróżnienie między powłoką a hostem. Don Jones, w swoim trafnie zatytułowanym poście The Shell vs. The Host, wyjaśnia, że użytkownik piszący na klawiaturze nie wchodzi w bezpośrednią interakcję z powłoką (lub silnikiem) PowerShella. Dokładniej mówiąc, użytkownik wchodzi w interakcję z aplikacją hosta (jak powershell.exe lub powershell_ise.exe), która tworzy przestrzeń uruchomieniową (instancję silnika PowerShell). Rozróżnienie to można zobaczyć wyświetlając zawartość właściwości Name zmiennej systemowej $Host obok zmiennej $ShellId. Zobaczysz, że jeśli zbadasz wartości dla trzech najbardziej powszechnych hostów PowerShell, wszystkie one używają tego samego silnika (powłoki), podczas gdy każdy z nich prezentuje inny interfejs użytkownika (host).
| Host | $Host.Name | $ShellId |
| PowerShell | ConsoleHost | Microsoft.PowerShell |
| PowerShell ISE | Windows PowerShell ISE Host | Microsoft.PowerShell |
| Visual Studio Package Manager Console | Package Manager Host | Microsoft.PowerShell |
Inne hosty PowerShell mogą potencjalnie mieć inne wartości $ShellId (na przykład niektóre z dostępnych bezpłatnie IDE PowerShell obejmują PowerGUI, PowerShell Analyzer i PowerShell Plus, ale nie sprawdziłem ich wartości $ShellId).
Profil PowerShella
Profil PowerShella to nic innego jak wymyślna nazwa skryptu, który jest uruchamiany podczas startu hosta PowerShella. Cytując standardową pomoc PowerShell na temat about_profiles, „Możesz użyć profilu jako skryptu logowania, aby dostosować środowisko. Można dodawać polecenia, aliasy, funkcje, zmienne, snap-iny, moduły i napędy Windows PowerShell. Można również dodać do profilu inne elementy specyficzne dla sesji, aby były one dostępne w każdej sesji bez konieczności ich importowania lub ponownego tworzenia.”
Każdy host PowerShell obsługuje w rzeczywistości dwa profile, jeden na poziomie użytkownika, odrębny dla każdego użytkownika, a drugi na poziomie systemu, wspólny dla wszystkich użytkowników. Powinien to być dobrze znany paradygmat, który widziałeś w wielu aplikacjach Windows. PowerShell dodaje jednak swój własny, unikalny zwrot: rozróżnia poziom hosta (jeden profil dla każdego hosta) i poziom systemu (jeden wspólny profil dla wszystkich hostów).
W ten sposób, biorąc wszystkie kombinacje użytkowników i hostów, możesz potencjalnie użyć dowolnego (lub wszystkich) z czterech różnych profili:
- AllUsersAllHosts
- AllUsersCurrentHost
- CurrentUserAllHosts
- CurrentUserCurrentHost
Profile te wszystkie pokojowo współistnieją, więc musisz być świadomy pierwszeństwa – są one wymienione powyżej w kolejności wykonywania. Jeśli zdefiniowalibyśmy tę samą zmienną we wszystkich czterech profilach, to po uruchomieniu hosta PowerShell i otrzymaniu monitu zmienna ta będzie miała wartość przypisaną przez ostatni profil CurrentUserCurrentHost, ponieważ każdy kolejno przetwarzany profil będzie nadpisywał tę zmienną swoją wartością. Innym przykładem, pokazującym współpracę między profilami, a nie rywalizację, może być inkrementacja zmiennej. Najpierw zdefiniuj i zainicjuj ją do wartości początkowej (np. $someVar = 0) w AllUsersAllHosts, a następnie inkrementuj ją w każdym z pozostałych profili (np. $someVar++ lub może $someVar += 5 w zależności od tego, co chcesz z nią zrobić).
Jeśli chodzi o to, którego z czterech użyć, zależy to w dużej mierze od twoich własnych potrzeb: jeśli używasz dedykowanego komputera (tzn. nie dzielonego z nikim innym), nie musisz się martwić o profile „wszyscy użytkownicy”. Jeśli używasz wielu hostów, możesz chcieć rozróżnić niektóre rzeczy pomiędzy profilem „wszystkich hostów” a profilem konkretnego hosta. Podam więcej szczegółów na ten temat poniżej w „How Many Profiles Do You Need?”
The $Profile Variable
Aby utworzyć lub edytować którykolwiek z profili, oczywiście, musisz wiedzieć, gdzie je znaleźć. PowerShell sam może łatwo powiedzieć, ale może również po prostu otworzyć jeden z nich do edycji bez konieczności wyraźnego zawracania sobie głowy ścieżką. Aby zobaczyć ścieżkę, wyświetl wartość zmiennej $Profile. Ujawnia ona pojedynczą ścieżkę do pliku, która jest ścieżką do profilu CurrentUserCurrentHost. PowerShell_profile.ps1
Zauważ, że to nie daje żadnego roszczenia o tym, czy plik istnieje, tylko że jest to ścieżka, którą musi mieć, jeśli istnieje. Aby sprawdzić istnienie, użyj Test-Path:
|
1
2
|
PS> Test-Path $Profile
True
|
Jeśli profil nie istnieje, możesz go łatwo utworzyć:
|
1
|
PS> New-Item -Type file -Path $Profile -Force
|
A jeśli chcesz mieć to w skrypcie, możesz wtedy połączyć powyższe, tworząc plik tylko w razie potrzeby:
|
1
2
|
PS> if (!(Test-Path $Profile)) {
New-Item -Type file -Path $Profile -Force }
|
Na koniec, aby edytować profil, po prostu wywołaj swój ulubiony edytor na pliku, lub zawsze możesz użyć wszechobecnego edytora Notatnika:
|
1
|
PS> notepad $Profile
|
Wszystkie powyższe przykłady dotyczą profilu „domyślnego” (CurrentUserCurrentHost), jak wspomniano. Ale możesz zastosować wszystkie te same polecenia do dowolnego z czterech profili przez konkretne odniesienie; każdy z nich daje taki sam wynik:
|
1
2
|
PS> notepad $Profile
PS> notepad $Profile.CurrentUserCurrentHost
|
Zastąp dowolną z pozostałych trzech nazw właściwości profilu, aby uzyskać dostęp do jednego z nie-domyślnych profili.
Zauważ, że tworzenie lub zapisywanie plików w katalogach systemowych (gdzie przechowywane są profile „wszystkich użytkowników”) może być trudne.
Możesz to zrobić z niektórymi narzędziami Microsoftu (np. Notatnik), ale nie możesz z niektórymi nie-Microsoftowymi narzędziami (np. mój ulubiony edytor, vim). Co ciekawe, vim udawał, że działa dla mnie, ale w rzeczywistości tak nie było: Mogłem utworzyć plik, całkowicie zamknąć edytor, następnie ponownie otworzyć edytor i przywołać plik – jednak plik nie pojawił się w Eksploratorze Windows, ani nie był widziany przez PowerShell podczas uruchamiania! (Nie do końca znam przyczynę tego problemu, ale nie jest ona spowodowana brakiem podwyższonych uprawnień).
Z drugiej strony, Notatnik najwyraźniej zna tajne zaklęcie, ponieważ działa zgodnie z oczekiwaniami. Innym obejściem jest utworzenie profilu „wszyscy użytkownicy” we własnym katalogu użytkownika, a następnie skopiowanie lub przeniesienie go do odpowiedniego katalogu systemowego.
Nazwy plików profili & Lokalizacje
Poprzednia sekcja wyjaśniła, jak edytować dowolny z twoich profili bez faktycznej wiedzy o tym, gdzie są w systemie plików, ale jesteś programistą; masz wrodzony przymus, aby wiedzieć, gdzie się ukrywają! Tabela pokazuje ścieżkę do każdego z nich. ( HostId to placeholder, wyjaśnione za chwilę.)
| Profile | Location |
| AllUsersAllHosts | $PsHomeProfile.ps1 |
| AllUsersCurrentHost | $PsHome_profile.ps1 |
| CurrentUserAllHosts | $HomeDocumentsWindowsPowerShell_profile.ps1 |
| CurrentUserCurrentHost | $HomeDocumentsWindowsPowerShell_profile.ps1 |
Błędem, który widziałem w wielu artykułach dostępnych w sieci jest to, że profile „wszystkich użytkowników” znajdują się pod $env:WinDir\System32. Jest to błędne ! $PsHome może przypadkowo rozwiązać do $env:WinDir\System32 dla niektórych hostów, ale nie dla wszystkich. Jako przykład, w moim systemie konsola menedżera pakietów Visual Studio przechowuje swoje profile „wszystkich użytkowników” pod $env:WinDir\SysWOW64. (Ten błąd pojawia się nawet w artykułach z bardzo renomowanych źródeł, takich jak ten artykuł MSDN.)
Przeglądając lokalizacje, łatwo jest zrozumieć konwencje nazewnictwa. Profile na poziomie systemu – te dla wszystkich użytkowników – znajdują się w katalogu systemowym, na który wskazuje $PsHome. Profile użytkownika znajdują się w katalogu domowym każdego użytkownika. Jedynym punktem, który wymaga wyjaśnienia jest HostId pokazany w tabeli dla profili specyficznych dla hosta. Niestety, ten identyfikator hosta nie ma bezpośredniego podobieństwa do opisu hosta ani do właściwości $Host.Name! Sposobem na odkrycie HostId jest po prostu wyświetlenie wartości zmiennej $Profile, ponieważ jest ona częścią ścieżki. Dla wygody, oto wartości HostId dla najczęściej występujących hostów:
| Host | HostId | $Host.Name |
| PowerShell | Microsoft.PowerShell | ConsoleHost |
| PowerShell ISE | Microsoft.PowerShellISE | Windows PowerShell ISE Host |
| Visual Studio Package Manager Console | NuGet | Package Manager Host |
Kolejny błąd tam na wolności, choć mniej powszechny, jest taki, że HostId jest odpowiednikiem wspomnianej wcześniej zmiennej $ShellId. To jest błędne! Jak zauważyłeś, wszystkie trzy wspólne hosty pokazane powyżej mają ten sam $ShellId, a to przypadkowo pasuje do HostId tylko dla standardowego hosta PowerShell. (Ten błąd pojawia się na przykład w książce Windows PowerShell Unleashed.)
Ile profili potrzebujesz?
Każdy standardowy system Windows ma dwa profile dla standardowego hosta PowerShell, dwa dla hosta PowerShell ISE i dwa dla wszystkich hostów – w sumie sześć jako minimum. Dodaj w VS menedżer pakietów, który pokazałem, to dwa więcej. Dodaj inne IDE PowerShella – dwa więcej dla każdego z nich. Jak zarządzasz tak wieloma profilami?
Interpretując oficjalną doktrynę MSDN ( about_profiles) rozważ rozwiązanie trójstronne.
- Po pierwsze, umieść naprawdę wspólne rzeczy w
AllUsersAllHost. - Po drugie, jeśli istnieją jakieś osobliwości w poszczególnych hostach, użyj
AllUsersCurrentHostdla tych niepoprawnych hostów. - Na koniec, pozwól każdemu użytkownikowi zarządzać jego własnymi preferencjami i ustawieniami w profilach użytkownika.
Ale znowu, może być wiele różnych profili dla „bieżącego hosta”, zarówno na poziomie systemu, jak i na poziomie użytkownika. Jednym z dobrych odniesień, gdy zastanawiasz się nad swoimi wyborami tutaj, jest post Eda Wilsona (The Scripting Guy) Deciding Between One or Multiple PowerShell Profiles. Zawiera on tam listę zalet i wad wyboru pomiędzy jednym profilem a wieloma profilami. Ale według mnie, zalety jednego profilu znacznie przewyższają zalety wielu profili. Potrzeba trochę więcej pracy, aby go skonfigurować, ale nadal można uwzględnić różnice specyficzne dla hosta, mając wszystko w jednym miejscu, co czyni go znacznie łatwiejszym do utrzymania w czasie.
Większość rzeczy w twoim profilu będzie prawdopodobnie wspólna dla każdego hosta, więc używanie jednego profilu oznacza, że wszelkie zmiany w dół drogi będą dokonywane w dokładnie jednym pliku. Dla rzeczy, które różnią się między hostami, po prostu dołącz sekcję specyficzną dla każdego hosta, na którym ci zależy. Mój zawiera coś takiego:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
if ($Host.Name -eq 'ConsoleHost’)
{
Import-Module PSReadline
# odróżnij verbose od warnings!
$privData = (Get-Host).PrivateData
$privData.VerboseForegroundColor = „cyan”
}
elseif ($Host.Name -like '*ISE Host’)
{
Start-Steroids
Import-Module PsIseProjectExplorer
}
if (!$env:github_shell)
{
# nie jestem pewien dlaczego, ale to nie powiedzie się w hoście git-flavored
Add-PSSnapin Microsoft.TeamFoundation.PowerShell
}
|
Zauważ, jak identyfikuję bieżącego hosta z $Host.Name, a następnie selektywnie wykonuję kod. Powyżej widzisz przykłady dla standardowego hosta PowerShell, jak również dla hosta PowerShell ISE. Dla tych pierwszych ładuje rozszerzenie PSReadline, które działa tylko w hoście PowerShell. Dla tego drugiego ładuje PsISEProjectExplorer i moduł ISE Steroids, z których oba mogą działać tylko w środowisku ISE.
Na koniec, jeśli używasz Git i konkretny instalator, którego użyłeś, utworzył dla ciebie hosta Git PowerShell, zauważ, że nie można go odróżnić od standardowego hosta PowerShell przez $Host.Name. Zamiast tego zidentyfikowałem unikalnie zdefiniowaną zmienną, $env:github_shell, która jest obecna tylko w hoście Git-flavored.
Co umieścić w swoim profilu
Odpowiedź na to pytanie zależy od twoich indywidualnych potrzeb, więc musi być bardzo abstrakcyjna: umieść w swoim profilu to, czego możesz użyć, aby być bardziej produktywnym. Nie ma zatem jednej odpowiedzi na to pytanie, ale z pewnością mogę podać kilka sugestii, które pobudzą twoją kreatywność. Właśnie widziałeś powyżej kilka przykładów importowania modułów stron trzecich, aby dodać funkcjonalność do danego hosta. Oprócz importu modułów, poniższe sekcje zawierają tylko kilka pomysłów, abyś mógł się zastanowić, co możesz chcieć tam umieścić. Spójrz także na Co jest w twoim pliku PowerShell `profile.ps1`? (na StackOverflow) po wiele więcej przykładów.
Aliasy
Wiele wbudowanych cmdletów PowerShell ma aliasy; niektóre mają wiele aliasów. Możesz na przykład użyć ls lub dir lub gci zamiast wpisywać Get-ChildItem. Dla tych, których używasz regularnie, a które nie zapewniają aliasów (lub dla własnych funkcji i cmdletów) możesz utworzyć własne aliasy za pomocą Set-Alias. Set-Alias jest odpowiednie, jeśli chcesz po prostu skrócić nazwę cmdleta lub funkcji. Czasami jednak możesz chcieć, aby alias zawierał, na przykład, nazwę cmdleta plus parametr, którego zawsze używasz. W takich przypadkach można emulować alias za pomocą prostej funkcji. Aby to zilustrować, rozważmy cmdlet Import-Module. Używam go często i wolę, aby wszystkie moje często używane polecenia cmdlet używały tylko pierwszej litery każdego elementu. To ustawia alias im, aby to zrobić:
|
1
|
Set-Alias im Import-Module
|
Ale będąc deweloperem, muszę również często używać Import-Module z przełącznikiem -Force. Więc w tym celu muszę uciec się do funkcji. Dla mojej konwencji nazewnictwa, dodaję pierwszą literę przełącznika, stąd imf tutaj:
|
1
|
function imf($name) { Import-Module $name -force }
|
Mogę wtedy użyć np. im foobar do wykonania waniliowego importu, lub imf foobar do importu z -Force zastosowanym.
Proste funkcje
Funkcje zostały właśnie wspomniane jako środek do tworzenia pseudoaliasów, czyli zasadniczo do oszczędzenia pisania na klawiaturze. Ale, oczywiście, nie są one ograniczone do tego celu. Możesz chcieć zawrzeć w swoim profilu różne „one-linery”, które zarówno oszczędzają pisanie, jak i konieczność pamiętania szczegółów cmdletów, których używasz rzadziej. Szybko, jak wyświetlić 50 ostatnich pozycji w historii poleceń? Nie jesteś pewien? cmdlet, którego należy użyć to Get-History (ma on standardowy alias składający się tylko z litery h). Czy łatwo jest zapamiętać Get-History -Count 50 lub po prostu h50? Oto moja definicja dla h50 (i h10 wrzucone tylko na dobrą sprawę):
|
1
2
|
function h50 { Get-History -Count 50 }
function h10 { Get-History -Count 10 }
|
Tutaj jest bardziej interesująca funkcja. Jak ujawniłbyś cmdlet kryjący się za aliasem, ścieżkę do pliku wykonywalnego podając tylko nazwę programu, zestawy parametrów dostępne dla danego cmdleta, czy zawartość funkcji zdefiniowanej przez użytkownika? Do tego wszystkiego używam tego one-linera (nazwanego tak samo jak polecenie unixowe/linuxowe):
|
1
|
function which($cmd) { (Get-Command $cmd).Definition }
|
Oto kilka wyników użycia tego:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
PS> which h
Get-.History
PS> which notepad
C:\Windows\system32\notepad.exe
PS> which which
param($cmd)
(Get-Command $cmd).Definicja
PS> which import-module
Import-Module <string> <string> -.PSSession <PSSession>
Import-Module <string> -CimSession <CimSession>
|
Na koniec, kolejny poręczny one-liner, który znów działa jak polecenie unix/linux, zgłaszając twoją nazwę użytkownika z kwalifikacją domeny:
|
1
|
function whoami { (get-content env:\userdomain) + „\” + (get-content env:\username }
|
Złożone funkcje
Jest prawdopodobne, że w trakcie swojej pracy stworzysz kilka funkcji użytkowych, które są znacznie bardziej skomplikowane niż prosty one-liner. Mógłbyś, oczywiście, po prostu osadzić je w swoim profilu, ale to zwykle czyni twój profil długim i niechlujnym. Jeśli masz kolekcję takich funkcji, zawsze możesz zorganizować je w prawdziwy moduł PowerShell, a następnie po prostu dodać Import-Module w swoim profilu, aby je wprowadzić. Dla czegoś pomiędzy tymi dwoma ekstremami, rozważ to podejście. W moim profilu mam tę sekwencję poleceń, która wprowadza wszystkie skrypty w moim lokalnym katalogu profile_scripts do zakresu przy uruchomieniu:
|
1
2
3
|
Resolve-Path $PSScriptRoot\profile_scripts\*.ps1 |
Where-Object { -not ($_.ProviderPath.Contains(„.Tests.”)) } |
Foreach-Object { . $_.ProviderPath }
|
$PSScriptRoot jest standardową zmienną systemową, która istnieje tylko w kontekście działającego skryptu. Rozwiązuje się ona do $Home
Wykonywanie akcji
Poprzednie elementy w tej sekcji są pasywne; definiują rzeczy do użycia w przyszłości po uruchomieniu systemu. Ale możesz także dołączyć aktywne elementy, które wykonują się podczas uruchamiania. Bardzo polecam użycie cmdleta „nie pozwól mi strzelić sobie w stopę”:
|
1
|
Set-PSDebug -Strict
|
Języki, które są słabo typowane (np.JavaScript, PowerShell) dają ci możliwość bezpiecznej pracy lub nie, podczas gdy języki silnie typowane generalnie zmuszają cię do bezpiecznej pracy. Bezpiecznie oznacza przede wszystkim, że nie można używać zmiennej, zanim nie zostanie ona zadeklarowana. Zapobiega to nieumyślnym błędom w pisowni, które mogą spowodować nieopisane cierpienie, próbując dowiedzieć się, dlaczego twój kod nie działa. (Przypuszczalnie, ludzie zajmujący się językami o słabych typach uważają, że niektórzy ludzie mogą uważać, że bezpieczne działanie jest uciążliwe, więc dają taką możliwość). Po prostu umieść Set-PSDebug w swoim profilu. Bądź bezpieczny. Proszę.
Inne rodzaje działań, które możesz umieścić w swoim profilu to rzeczy takie jak wyświetlanie niektórych statystyk, np. czasu pracy, miejsca na dysku lub polityki wykonywania PowerShell. Jeśli administrujesz wieloma maszynami, możesz chcieć zobaczyć szczegóły na temat maszyny, do której się „zdalnie” podłączyłeś, aby upewnić się, że jesteś na tym komputerze, na którym myślisz, że jesteś (nazwa domeny, nazwa komputera, adres IP, itp.).
Zabezpieczanie Twojego profilu
Gdy masz do czynienia z komputerami, bezpieczeństwo zawsze musi być brane pod uwagę. Używasz zapory sieciowej i programu antywirusowego, aby zapewnić bezpieczeństwo systemu. Podobnie musisz rozważyć skrypty PowerShell, które uruchamiasz – w tym własne profile. PowerShell ma dobre wsparcie dla bezpieczeństwa, począwszy od domyślnego ustawienia nie pozwalającego na uruchamianie żadnych skryptów; po wyjęciu z pudełka można używać tylko poleceń PowerShell interaktywnie. Musisz otworzyć swój system na tyle, aby umożliwić wykonanie każdej pracy, którą musisz wykonać, ustawiając politykę wykonania komputera (zobacz Set-ExecutionPolicy).
Ale jak tylko zezwolisz na uruchamianie skryptów, istnieje szansa, że możesz nieumyślnie uruchomić skompromitowany skrypt. Nie jest to nic wyjątkowego dla skryptów PowerShell per se – wszystko na twoim komputerze może być skompromitowane – po prostu PowerShell pomaga złagodzić sytuację. Robi to poprzez umożliwienie ustawienia polityki wykonywania skryptów na różnych poziomach bezpieczeństwa, zgodnie z własnymi potrzebami. Można wymagać, aby każdy skrypt musiał być uwierzytelniony, lub aby tylko skrypty, które pobieramy były uwierzytelnione, wśród innych opcji. Uwierzytelnianie, w tym przypadku, odnosi się do podpisywania skryptów podpisem cyfrowym (zobacz Set-AuthenticodeSignature) tak, że jeśli plik zostanie zmodyfikowany (złośliwie lub nie), podpis cyfrowy wykryje ingerencję i uniemożliwi uruchomienie skryptu.
Zarządzanie bezpieczeństwem skryptów PowerShell (w tym profili), jednak nie jest trywialnym przedsięwzięciem. (To by ponad dwukrotnie zwiększyło długość tego artykułu!) Ale wiele dobrych informacji jest już dostępnych, aby Cię poprowadzić. Polecam zacząć od innego artykułu tutaj na Simple-Talk, Nicolas Prigent’s PowerShell Day-to-Day SysAdmin Tasks: Securing Scripts. Istnieje również kilka dobrych referencji we własnej dokumentacji PowerShell: about_signing daje dobre wprowadzenie do tematu; New-SelfSignedCertificate pozwala tworzyć własne certyfikaty samopodpisane, a Get-ChildItem for Certificate ujawnia mało znane różnice w Get-ChildItem podczas odwoływania się do sklepu z certyfikatami. Microsoft udostępnia starą, ale wciąż przydatną książkę Code-Signing Best Practices. Warto też zajrzeć do książki Geoffa Barda Signing PowerShell Scripts.
Get That Profile Out of the Way!
Teraz wiesz, jak skonfigurować swój profil, dlaczego jest on przydatny, co z nim zrobić i jak go chronić. Ale jak w przypadku każdej super mocy, musisz być świadomy jej ciemnej strony. Cóż, nie tyle ciemnej strony per se, ale że są czasy, że po prostu nie chcesz, aby twój profil (y), aby dostać się na swój sposób. Lub, bardziej przejmująco, profile innych ludzi.
Istnieją różne sytuacje, w których możesz chcieć faktycznie wykonać powershell.exe albo z dosłownym poleceniem lub plik skryptu do uruchomienia. Oto jeden z przykładów: powiedzmy, że utworzyłeś skrypt PowerShell, który chcesz udostępnić koledze. W przeciwieństwie do plików wsadowych, nie można po prostu dwukrotnie kliknąć skryptu PowerShell, aby go wykonać; jest to część modus operandi bezpieczeństwa PowerShell, aby utrzymać system w bezpiecznym stanie. Ale jest to łatwe do obejścia (nie żebym to polecał!) poprzez utworzenie standardowego skrótu do systemu Windows, który kieruje do powershell.exe z plikiem skryptu PowerShell jako parametrem.
Innym, być może bardziej legalnym zastosowaniem, byłoby uruchomienie skryptu lub polecenia PowerShell wewnątrz pliku kompilacji. Ponieważ MSBuild nie wie jak uruchamiać skrypty PowerShell, zazwyczaj wykonujesz skrypt przez dostarczenie go jako argument do powershell.exe.
Za każdym razem, gdy uruchamiasz powershell.exe, otwierasz nowego hosta PowerShell. A co się dzieje, gdy otwierasz hosta? Uruchamia dowolny (lub wszystkie) z Twoich czterech profili! Ale prawie za każdym razem, gdy otwierasz hosta przez bezpośrednie wywołanie powershell.exe, nie chcesz, aby twoje profile były uruchamiane, ani ze względu na koszty ogólne, ani ze względu na możliwe konflikty, które mogą się pojawić. Pamiętaj, że jeśli ktoś inny uruchamia build, w którym wprowadziłeś polecenie uruchamiania powershell.exe, to jest to jego profil, który zostanie uruchomiony na jego maszynie, a ty nie masz pojęcia, co może się tam czaić. Ponadto, nie chcesz uzależniać się od czegoś w profilu, ponieważ za pierwszym razem, gdy ktoś uruchomi twój build, kto nie wie o tej zależności, to (być może w tajemniczy sposób) zawiedzie. Tak więc najbezpieczniej jest po prostu przyjąć najlepszą praktykę ignorowania profili podczas wywoływania powershell.exe. (Nie chodzi mi o to, że powinieneś je ignorować, raczej o to, że powinieneś powiedzieć PowerShellowi, aby je ignorował, oczywiście!
Więc po tym całym napięciu, zakończenie może być nieco antyklimatyczne: po prostu dodaj -NoProfile jako parametr do powershell.exe.
Wniosek
Profil PowerShell jest twoim przyjacielem. Z mapą drogową przedstawioną w tym artykule, zobaczyłeś rodzaje profili dostępnych dla Ciebie i możesz wybrać te, które będą dla Ciebie pracować. Możesz też zdecydować się na użycie jednego profilu, wyróżniając wszelkie elementy specyficzne dla hosta w razie potrzeby. Profil jest proste, ale potężne narzędzie dostępne dla Ciebie, nie jest wcale skomplikowane w użyciu, a jego zastosowania są ograniczone tylko przez wyobraźnię. O jedynym minusem jest cały czas, który będziesz teraz spędzać na szukaniu przydatnych i sprytnych rzeczy do dodania do swojego profilu. (Czy wspomniałem, że powinieneś rozważyć włączenie modułu Go-Shell…?)
.