Redgate Hub

Mialatt egy PowerShell munkamenettel dolgozik, annak állapotát (vagy környezetét) számos módon módosíthatja: Importálhat modulokat, hozhat létre függvényeket, megadhat aliasokat vagy definiálhat változókat, hogy csak néhányat említsünk. De mindezek átmeneti jellegűek: hatásuk eltűnik, amint bezárja a PowerShell-munkamenetet. A PowerShell azonban biztosít egy PowerShell-profilnak nevezett mechanizmust, amely lehetővé teszi, hogy minden ilyen környezeti konstrukciót és beállítást újra létrehozzon minden egyes alkalommal, amikor új PowerShell-munkamenetet indít. És ha egy profil jó, nem lenne jobb több? Kiderült, hogy egyetlen PowerShell-munkamenet négy különböző profil bármelyikét (vagy mindegyiket) használhatja, és a különböző PowerShell-hostok még több profilválasztási lehetőséget biztosítanak: De valójában sokkal egyszerűbb a használata, mint amilyennek mindez látszik, ha egyszer megértjük, hogy az összes mozgó alkatrész hol helyezkedik el. Nézzük meg.

A héj a PowerShellben

A PowerShellben különbséget kell tenni a héj és a hoszt között. Don Jones a találóan The Shell vs. The Host című bejegyzésében elmagyarázza, hogy Ön – mint a billentyűzeten gépelő felhasználó – nem lép közvetlen kapcsolatba a PowerShell héjával (vagy motorjával). Pontosabban inkább egy olyan gazdalkalmazással (például powershell.exe vagy powershell_ise.exe) lépünk kapcsolatba, amely létrehoz egy futtatási teret (a PowerShell motor egy példányát). A különbséget ténylegesen láthatja, ha a $Host rendszerváltozó Name tulajdonságának tartalmát a $ShellId változó mellett megjeleníti. Ha megvizsgálja a három leggyakoribb PowerShell hoszt értékeit, láthatja, hogy mindegyik ugyanazt a motort (shell) használja, miközben mindegyik más-más felhasználói felületet (host) jelenít meg.

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

Más PowerShell hosztok esetleg más $ShellId értékekkel rendelkezhetnek (például a szabadon elérhető PowerShell IDE-k közül néhány PowerGUI, PowerShell Analyzer és PowerShell Plus, de nem ellenőriztem a $ShellId értékeiket).

A PowerShell profil

A PowerShell profil nem más, mint egy olyan szkript fantázianeve, amely a PowerShell állomás indításakor fut. A standard PowerShell súgó about_profiles című részét idézve: “A profilt bejelentkezési szkriptként használhatja a környezet testreszabására. Hozzáadhat parancsokat, aliasokat, függvényeket, változókat, beépülő modulokat, modulokat és Windows PowerShell meghajtókat. Más munkamenet-specifikus elemeket is hozzáadhat a profiljához, így azok minden munkamenetben rendelkezésre állnak anélkül, hogy importálni vagy újra létrehozni kellene őket.”

Minden PowerShell-állomás valójában két profilt támogat, az egyik felhasználói szintű, minden felhasználó számára különálló, a másik pedig rendszerszintű, minden felhasználó számára közös. Ez egy ismerős paradigma kell, hogy legyen, amit már sok Windows-alkalmazásnál láthatott. A PowerShell azonban hozzáteszi a saját egyedi csavarját: hasonlóan megkülönbözteti az állomásszintű (egy profil minden állomáshoz) és a rendszerszintű (egy közös profil minden állomáshoz) profilokat.

Így a felhasználók és a hosztok összes kombinációját figyelembe véve potenciálisan négy különböző profil bármelyikét (vagy mindegyikét) használhatja:

• AllUsersAllHosts
• AllUsersCurrentHost
• CurrentUsersAllHosts
• CurrentUserCurrentHost

Ezek a profilok mind békésen egymás mellett léteznek, így ezután tisztában kell lennie az elsőbbséggel – a fenti sorrendben szerepelnek. Ha mind a négy profilban ugyanazt a változót definiálnánk, akkor a változónak a PowerShell hoszt indítása után, amikor végre kap egy promptot, az utolsó, CurrentUserCurrentHost profil által kijelölt értéke lesz, mert minden egymást követő feldolgozott profil felülírja a változó értékét. Egy másik példa, amely inkább a profilok közötti együttműködést mutatja, mint a versengést, egy változó inkrementálása lehet. Először definiáljuk és inicializáljuk egy kezdőértékre (pl. $someVar = 0) a AllUsersAllHosts-ben, majd növeljük a többi profilban (pl. $someVar++ vagy esetleg $someVar += 5 attól függően, hogy mit akarunk vele csinálni).

Az, hogy a négy közül melyiket használjuk, nagyban függ a saját igényeinktől: ha saját számítógépet használunk (azaz nem osztjuk meg mással), nem kell az “összes felhasználó” profilok miatt aggódnunk. Ha több hosztot használ, akkor érdemes megkülönböztetni néhány dolgot az “összes hoszt” profil és egy adott hoszt profil között. Erről alább a “Hány profilra van szükséged?”

A $Profil változó

A profilok bármelyikének létrehozásához vagy szerkesztéséhez természetesen tudnod kell, hogy hol találod őket. Maga a PowerShell könnyen meg tudja mondani, de az is előfordulhat, hogy egyszerűen megnyit egyet szerkesztésre anélkül, hogy kifejezetten az elérési úttal kellene bajlódnia. Az elérési útvonal megtekintéséhez jelenítse meg a $Profile változó értékét. Ez egyetlen fájl elérési útját mutatja, amely a CurrentUserCurrentHost profil elérési útja. Egy szabványos PowerShell hosztban az enyém ezt mutatja:

Megjegyezzük, hogy ez nem állít semmit arról, hogy a fájl létezik-e, csak azt, hogy ez az az elérési útvonal, ahol lennie kell, ha létezik. A létezés ellenőrzéséhez használja a Test-Path parancsot:

Ha a profil nem létezik, egyszerűen létrehozhatja:

És ha azt szeretnénk, hogy egy scriptben legyen, akkor kombinálhatjuk a fentieket, csak szükség esetén létrehozva a fájlt:

A profil szerkesztéséhez végül csak hívjuk meg kedvenc szerkesztőnket a fájlra, vagy használhatjuk a mindenütt jelenlévő jegyzettömb-szerkesztőt is:

A fenti példák mind az “alapértelmezett” (CurrentUserCurrentHost) profilra vonatkoznak, ahogy említettük. De ugyanazokat a parancsokat alkalmazhatja a négy profil bármelyikére konkrét hivatkozással; ezek bármelyike ugyanazt az eredményt adja:

A másik három profil-tulajdonságnév bármelyikével helyettesítve elérhetjük a nem alapértelmezett profilok valamelyikét.

Profilok fájlnevei & Helyei

Az előző részben elmagyaráztuk, hogyan szerkesztheti bármelyik profilját anélkül, hogy ténylegesen tudná, hol vannak a fájlrendszerben, de ön fejlesztő; önnek veleszületett kényszere, hogy tudja, hol rejtőznek! A táblázat megmutatja mindegyiknek az elérési útvonalát. ( A HostId egy helyőrző, mindjárt elmagyarázzuk.)

Profile	Location
AllUsersAllHosts	$PsHome\profile.ps1
AllUsersCurrentHost	$PsHome\HostId_profile.ps1
CurrentUserAllHosts	$Home\Documents\WindowsPowerShell\profile.ps1
CurrentUserCurrentHost	$Home\Documents\WindowsPowerShell\HostId_profile.ps1

A helyeket áttekintve egyszerű megérteni a névadási konvenciókat. A rendszerszintű profilok – az összes felhasználóhoz tartozó profilok – a $PsHome által mutatott rendszerkönyvtárban vannak. A felhasználói szintű profilok az egyes felhasználók home könyvtárában találhatók. Az egyetlen pont, ami magyarázatra szorul, az a HostId, amely a táblázatban az állomásspecifikus profiloknál szerepel. Sajnos ez a hoszt azonosító nem mutat közvetlen hasonlóságot sem a hoszt leírásával, sem a $Host.Name tulajdonsággal! A HostId felfedezésének módja egyszerűen a $Profile változó értékének megjelenítése, mivel az az elérési útvonal részét képezi. Az egyszerűség kedvéért itt vannak a HostId értékei a leggyakoribb hosztokhoz:

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

Hány profilra van szükség?

Minden szabványos Windows-rendszerben két profil van a szabványos PowerShell-gazdához, kettő a PowerShell ISE-gazdához, és kettő az összes gazdához – összesen legalább hat. Ha hozzáadjuk az általam bemutatott VS csomagkezelőt, az még kettő. Adjunk hozzá más PowerShell IDE-ket – mindegyikhez még kettőt. Hogyan kezel ennyi profilt?

A hivatalos MSDN doktrínát ( about_profiles) értelmezve fontolja meg a hármas megoldást.

• Először a valóban közös dolgokat tedd a AllUsersAllHost-be.
• Második, ha bizonyos hosztoknál vannak sajátosságok, használjuk a AllUsersCurrentHost-t ezekre a rosszindulatú hosztokra.
• Végül hagyjuk, hogy minden felhasználó a saját preferenciáit és beállításait a felhasználó-specifikus profilokban kezelje.

De ismétlem, az “aktuális hoszt” számára sok különböző profil létezhet, mind rendszerszinten, mind felhasználói szinten. Egy jó referencia, ahogy itt a választási lehetőségeidet latolgatod, Ed Wilson (The Scripting Guy) posztja Deciding Between One or Multiple PowerShell Profiles. Ebben felsorolja az egy profil és a több profil közötti választás előnyeit és hátrányait. Számomra azonban az egyetlen profil előnyei messze felülmúlják a több profil előnyeit. Kicsit több munkát igényel a beállítása, de így is figyelembe tudja venni a hoszt-specifikus különbségeket, miközben minden egy helyen van, így idővel sokkal egyszerűbb karbantartani.

A profilod dolgainak nagy része valószínűleg közös lesz bármelyik hoszton, így az egyetlen profil használata azt jelenti, hogy minden későbbi változtatás pontosan egy fájlban történik. Azokra a dolgokra, amelyek különböznek az egyes hosztok között, csak egy külön szekciót kell beillesztened minden egyes hostra, amivel foglalkozol. Az enyém valami ilyesmit tartalmaz:

Figyeljük meg, hogyan azonosítom az aktuális hostot a $Host.Name segítségével, majd szelektíven végrehajtom a kódot. A fenti példákat a standard PowerShell hosztra és a PowerShell ISE hosztra is láthatja. Az előbbi esetében a PSReadline bővítményt tölti be, amely csak a PowerShell hostban működik. Az utóbbi esetében betölti a PsISEProjectExplorer és az ISE Steroids modult, amelyek mindketten csak az ISE környezetben működhetnek.

Végezetül, ha Git-et használ, és az adott telepítőprogram, amelyet használt, létrehozott egy Git PowerShell hosztot az Ön számára, vegye figyelembe, hogy azt nem lehet megkülönböztetni a szabványos PowerShell hosttól a $Host.Name. Ehelyett azonosítottam egy egyedileg definiált változót, a $env:github_shell-t, amely csak a Git-ízű hostban van jelen.

Mit tegyen a profiljába

A válasz erre a kérdésre az egyéni igényeitől függ, ezért nagyon elvontnak kell lennie: tegye a profiljába azt, amivel produktívabb lehet. Erre tehát nincs egységes válasz, de néhány javaslatot biztosan tudok adni, hogy a kreativitásodat felpezsdítsem. Az imént láttál fentebb néhány példát arra, hogy harmadik féltől származó modulokat importálhatsz, hogy az adott tárhelyet funkcionalitással egészítsd ki. A modulimporton kívül a következő szakaszok csak néhány ötletet adnak, hogy elgondolkodjon azon, hogy mit érdemes beletenni. Vessen egy pillantást a Mi van a PowerShell `profile.ps1` fájlban? (a StackOverflow oldalon) további példákért.

Aliázisok

Néhány beépített PowerShell-cmdletnek vannak aliasai; némelyiknek több aliasuk is van. Használhatja például a Get-ChildItem beírása helyett a ls vagy a dir vagy a gci parancsot. Azoknál a rendszeresen használt parancsoknál, amelyek nem biztosítanak aliasokat (vagy a saját egyéni függvények és cmdletek esetében), a Set-Alias segítségével létrehozhat saját aliasokat. A Set-Alias akkor megfelelő, ha csak a cmdlet vagy a függvény nevét szeretné lerövidíteni. Néha azonban szükség lehet arra, hogy egy alias tartalmazzon például egy cmdlet nevet és egy olyan paramétert, amelyet általában mindig használ. Ilyenkor egy egyszerű függvénnyel emulálhat egy aliast. Ennek illusztrálására tekintsük a Import-Module cmdletet. Gyakran használom, és jobban szeretem, ha minden gyakran használt cmdletem csak az egyes összetevők első betűjét használja. Ez beállítja az im aliast erre a célra:

De mivel fejlesztő vagyok, nekem is gyakran kell használnom az Import-Module-et a -Force kapcsolóval. Így ehhez egy függvényhez kell folyamodnom. Az én elnevezési konvenciómhoz a kapcsoló első betűjét adom hozzá, ezért itt imf:

Azután használhatom pl. a im foobar-t a vanília importáláshoz, vagy a imf foobar-t a -Force alkalmazásával történő importáláshoz.

Egyszerű függvények

A függvényeket csak úgy említettük, mint az ál-aliázisok létrehozásának eszközét, azaz lényegében a gépelés megtakarítását. De természetesen nem korlátozódnak erre a célra. Érdemes lehet különféle “egysorosokat” felvenni a profilodba, amelyekkel egyrészt megspórolhatod a gépelést, másrészt nem kell megjegyezned a ritkábban használt cmdletek részleteit. Gyorsan, hogyan jelenítheted meg a parancstörténeted utolsó 50 elemét? Nem biztos? A használandó cmdlet a Get-History (szabványos aliasa csak a h betű). Könnyen megjegyezhető a Get-History -Count 50 vagy csak a h50? Íme a h50 definíciója (és a biztonság kedvéért egy h10 is):

Itt egy érdekesebb függvény. Hogyan fedhetnénk fel egy alias mögötti cmdletet, egy futtatható program elérési útvonalát, ha csak a program nevét adjuk meg, egy adott cmdlethez elérhető paraméterkészleteket, vagy egy felhasználó által definiált függvény tartalmát? Én minderre ezt az egysorost használom (a hasonló feladatot ellátó unix/linux parancs után elnevezve):

Itt van néhány eredmény a használatából:

Finally, egy másik praktikus egysoros, amely ismét úgy működik, mint a unix/linux parancs, és a domain-képes felhasználónevet jelenti:

Bonyolult függvények

Valószínű, hogy munkája során létrehoz néhány olyan segédfüggvényt, amelyek sokkal bonyolultabbak, mint egy egyszerű egysoros. Természetesen beágyazhatod őket egyszerűen a profilodba, de ez hajlamos hosszúvá és rendezetlenné tenni a profilodat. Ha ilyen függvények gyűjteménye van, akkor mindig megszervezheted őket egy valódi PowerShell-modulba, majd egyszerűen hozzáadhatsz egy Import-Module-t a profilodban, hogy behozd őket. Ha a két véglet között helyezkedik el, fontolja meg ezt a megközelítést. Az én profilomban a következő parancssorozat van, amely a helyi profile_scripts könyvtáramban lévő összes szkriptet a hatókörbe hozza indításkor:

$PSScriptRoot egy szabványos rendszerváltozó, amely csak egy futó szkript kontextusában létezik. Feloldása $Home\Dokumentumok\WindowsPowerShell\. Így a profile_scripts könyvtáram ezen az útvonalon található. Minden szkript (a tesztszkriptek kivételével) pontforrással rendelkezik, így láthatóvá válik az aktuális hatókörében, amint az indítás után megjelenik egy prompt.

Műveletek végrehajtása

Az előző elemek ebben a szakaszban mind passzívak; olyan dolgokat határoznak meg, amelyeket az indítás után egy későbbi időpontban használhat. De tartalmazhat aktív elemeket is, amelyek az indítás során hajtódnak végre. Nagyon ajánlom a “ne hagyd, hogy lábon lőjem magam” cmdlet használatát:

A gyengén tipizált nyelvek (pl.pl. JavaScript, PowerShell) lehetőséget adnak a biztonságos vagy nem biztonságos munkavégzésre, míg az erősen tipizált nyelvek általában rákényszerítenek a biztonságos munkavégzésre. A biztonságosan elsősorban azt jelenti, hogy nem engedélyezzük egy változó használatát a deklarálás előtt. Ez megakadályozza, hogy a véletlen elgépelés mérhetetlen bosszúságot okozzon Önnek, amikor megpróbálja kitalálni, hogy miért nem működik a kódja. (Feltehetően a gyengén tipizált nyelvek használói úgy gondolják, hogy néhány embernek megterhelő lehet a biztonságos működés, ezért adnak erre lehetőséget). Csak írd be a Set-PSDebug-at a profilodba. Légy biztos a dolgodban. Please.

A profilodba más típusú műveleteket is beírhatsz, például néhány statisztika megjelenítését, például az üzemidőt, a lemezterületet vagy a PowerShell végrehajtási szabályzatát. Ha több gépet adminisztrál, akkor esetleg szeretné látni annak a gépnek a részleteit, amelyre “távolról” belépett, hogy megbizonyosodjon arról, hogy azon a dobozon van, amelyre gondol (tartománynév, számítógépnév, IP-cím stb.).

A profiljának védelme

Amikor számítógépekkel foglalkozik, mindig figyelembe kell venni a biztonságot. Tűzfalat és vírusirtót használsz, hogy megpróbáld biztonságban tartani a rendszeredet. Hasonlóképpen figyelembe kell venned a PowerShell szkripteket is, amelyeket futtatsz – beleértve a saját profiljaidat is. A PowerShell jól támogatja a biztonságot, kezdve azzal az alapértelmezett beállítással, hogy nem engedi a parancsfájlok futtatását; a dobozból kivéve csak interaktívan használhatja a PowerShell parancsokat. A számítógép futtatási házirendjének beállításával (lásd: Set-ExecutionPolicy) éppen csak annyira kell megnyitnia a rendszert, hogy a szükséges munkát el tudja végezni.

Mihelyt azonban engedélyezi a parancsfájlok futtatását, fennáll az esélye annak, hogy véletlenül egy kompromittált parancsfájlt futtat. Ez önmagában nem csak a PowerShell szkriptekre jellemző – a számítógépén bármi veszélyeztetett lehet -, csak a PowerShell segít enyhíteni a helyzetet. Mindezt úgy teszi, hogy lehetővé teszi a futtatási házirend különböző biztonsági szintek beállítását a saját igényei szerint. Többek között megkövetelheti, hogy minden szkriptet hitelesíteni kelljen, vagy csak a letöltött szkripteket kelljen hitelesíteni. A hitelesítés ebben az esetben a szkriptek digitális aláírással való aláírására utal (lásd Set-AuthenticodeSignature), hogy ha egy fájlt módosítanának (akár rosszindulatúan, akár nem), a digitális aláírás észlelje a manipulációt, és megakadályozza a szkript futtatását.

A PowerShell-szkriptek (beleértve a profilokat is) biztonságának kezelése azonban nem triviális vállalkozás. (Ez több mint kétszeresére növelné ennek a cikknek a hosszát!) De már most is sok jó információ áll rendelkezésre, amelyek útmutatást adnak. Javaslom, hogy kezdd egy másik cikkel itt a Simple-Talkon, Nicolas Prigent PowerShell Day-to-Day SysAdmin Tasks című cikkével: Securing Scripts. A PowerShell saját dokumentációjában is számos jó hivatkozás található: az about_signing jó bevezetést ad a témába; a New-SelfSignedCertificate segítségével saját, önaláírt tanúsítványokat hozhatsz létre, a Get-ChildItem for Certificate pedig feltárja a Get-ChildItem kevéssé ismert különbségeit a tanúsítványtárolóra való hivatkozáskor. A Microsoft egy régi, de még mindig hasznos hivatkozást ad a Kódaláírás legjobb gyakorlataihoz. Geoff Bard Signing PowerShell Scripts című könyvét pedig szintén érdemes megnézni.

Get That Profile Out of the Way!

Most már tudja, hogyan állítsa be a profilját, miért hasznos, mit csináljon vele, és hogyan védje meg. De mint minden szupererőnek, ennek is tisztában kell lenned a sötét oldalával. Nos, nem is annyira a sötét oldaláról, hanem arról, hogy vannak olyan helyzetek, amikor egyszerűen nem akarod, hogy a profilod(ok) az utadba álljanak. Vagy, ami még fájdalmasabb, más emberek profiljai.

Vanak különböző helyzetek, amikor ténylegesen végre akarja hajtani a powershell.exe-t, akár szó szerinti paranccsal, akár egy szkriptfájl futtatásával. Íme csak egy példa: mondjuk, hogy készített egy PowerShell szkriptet, amelyet meg szeretne osztani egy kollégájával. A kötegelt fájlokkal ellentétben egy PowerShell szkriptet nem lehet egyszerűen duplán kattintani, hogy futtassa azt; ez része a PowerShell biztonsági módszereinek, hogy a rendszer biztonságban legyen. Ez azonban könnyen megkerülhető (nem mintha ezt javasolnám!), ha létrehozunk egy szabványos Windows parancsikont, amely a powershell.exe parancsfájlt célozza meg, a PowerShell szkriptfájlt paraméterként megadva.

Egy másik, talán még legitimebb felhasználási mód lehet egy PowerShell szkript vagy parancs futtatása egy build-fájlon belül. Mivel az MSBuild nem tudja, hogyan kell futtatni a PowerShell szkripteket, a szkriptet általában úgy kell futtatni, hogy a powershell.exe parancsnak argumentumként megadjuk.

Amikor azonban a powershell.exe parancsot futtatjuk, egy új PowerShell hosztot nyitunk meg. És mi történik, amikor megnyit egy hosztot? A négy profil bármelyikét (vagy mindegyiket) futtatja! De szinte mindig, amikor a powershell.exe közvetlen meghívásával nyit meg egy hosztot, nem akarja, hogy a profiljai fussanak, sem a többletköltségek, sem a lehetséges konfliktusok miatt, amelyek ebből adódhatnak. Ne feledje, ha valaki más is futtat egy olyan buildet, ahol Ön bevezetett egy parancsot a powershell.exe futtatására, akkor az ő profilja fog futni a gépén, és Önnek fogalma sincs arról, hogy mi rejtőzik ott. Továbbá, nem akarsz valamitől függeni egy profilban, mert amikor valaki először futtatja a buildedet, aki nem tud a függőségről, az (esetleg rejtélyes módon) sikertelen lesz. Tehát a legbiztonságosabb, ha egyszerűen elfogadjuk azt a legjobb gyakorlatot, hogy a powershell.exe meghívásakor mindig figyelmen kívül hagyjuk a profilokat. (Természetesen nem úgy értem, hogy figyelmen kívül kell hagynunk őket, hanem inkább úgy, hogy meg kell mondanunk a PowerShellnek, hogy hagyja figyelmen kívül őket!

Az izgalmas felvezetés után tehát a végkifejlet kissé antiklimatikus lehet: egyszerűen adjunk hozzá egy -NoProfile-t paraméterként a powershell.exe-hez.

Következtetés

A PowerShell profil a barátunk. Az ebben a cikkben ismertetett útiterv segítségével megismerkedtél a rendelkezésedre álló profiltípusokkal, és kiválaszthatod a számodra megfelelőt. Vagy dönthet úgy is, hogy egyetlen profilt használ, szükség szerint megkülönböztetve az állomásspecifikus elemeket. A profil egy egyszerű, mégis hatékony eszköz áll az Ön rendelkezésére, használata egyáltalán nem bonyolult, és felhasználásának csak a képzelete szab határt. Körülbelül az egyetlen hátránya az az idő, amit mostantól azzal fog tölteni, hogy praktikus és okos dolgokat keressen, amelyeket hozzáadhat a profiljához. (Említettem már, hogy érdemes lenne megnézni a Go-Shell modul beépítését…?)