Redgate Hub

În timp ce lucrați cu o sesiune PowerShell, îi puteți modifica starea (sau mediul) în mai multe moduri: Ați putea să importați module, să creați funcții, să specificați alias-uri sau să definiți variabile, pentru a numi doar câteva. Dar toate acestea sunt tranzitorii: efectele lor dispar de îndată ce închideți sesiunea PowerShell. Cu toate acestea, PowerShell oferă un mecanism, numit profil PowerShell, care vă permite să recreați orice astfel de construcții și setări de mediu de fiecare dată când porniți o nouă sesiune PowerShell. Și dacă un profil este bun, mai multe nu ar fi mai bine? Se pare că o singură sesiune PowerShell poate utiliza unul (sau toate) dintre cele patru profiluri diferite, iar diferite gazde PowerShell oferă și mai multe opțiuni de profil: Dar, de fapt, este mult mai simplu de utilizat decât ar putea părea toate acestea, odată ce apreciați unde se potrivesc toate piesele mobile. Să aruncăm o privire.

Shell-ul în PowerShell

Există o distincție între shell și gazdă în PowerShell. Don Jones, în postarea sa intitulată pe bună dreptate The Shell vs. The Host, explică faptul că dumneavoastră – ca utilizator care tastați la tastatură – nu interacționați direct cu shell-ul (sau motorul) PowerShell. Mai exact, interacționați cu o aplicație gazdă (cum ar fi powershell.exe sau powershell_ise.exe) care creează un spațiu de execuție (o instanță a motorului PowerShell). Puteți vedea de fapt distincția prin afișarea conținutului proprietății Name a variabilei de sistem $Host alături de variabila $ShellId. Veți vedea că, dacă examinați valorile pentru cele mai comune trei gazde PowerShell, toate folosesc același motor (shell), în timp ce fiecare prezintă o interfață utilizator (gazdă) diferită.

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

Alte gazde PowerShell ar putea avea valori $ShellId diferite (de exemplu, unele dintre IDE-urile PowerShell disponibile gratuit includ PowerGUI, PowerShell Analyzer și PowerShell Plus, dar nu am verificat valorile lor $ShellId).

Profilul PowerShell

Un profil PowerShell nu este altceva decât un nume sofisticat pentru un script care se execută la pornirea unei gazde PowerShell. Citând ajutorul standard PowerShell pe about_profiles, „Puteți utiliza profilul ca un script de conectare pentru a personaliza mediul. Puteți adăuga comenzi, alias-uri, funcții, variabile, snap-ins, module și unități Windows PowerShell. De asemenea, puteți adăuga alte elemente specifice sesiunii la profilul dumneavoastră, astfel încât acestea să fie disponibile în fiecare sesiune fără a fi nevoie să le importați sau să le recreați.”

Care gazdă PowerShell suportă de fapt două profiluri, unul este la nivel de utilizator, distinct pentru fiecare utilizator, iar celălalt este la nivel de sistem, comun tuturor utilizatorilor. Aceasta ar trebui să fie o paradigmă familiară pe care o veți fi văzut-o la multe aplicații Windows. Cu toate acestea, PowerShell adaugă propria sa întorsătură unică: distinge în mod similar între nivelul de gazdă (un profil pentru fiecare gazdă) și nivelul de sistem (un profil comun pentru toate gazdele).

Așa, luând toate combinațiile de utilizatori și gazde, ați putea utiliza potențial oricare (sau toate) din patru profiluri diferite:

• AllUsersAllHosts
• AllUsersCurrentHost
• CurrentUserAllHosts
• CurrentUserCurrentHost

Toate aceste profiluri coexistă în mod pașnic, astfel încât trebuie apoi să fiți conștienți de precedență – ele sunt enumerate mai sus în ordinea executării. Dacă ar fi să definiți aceeași variabilă în toate cele patru profiluri, variabila va avea, după ce veți lansa o gazdă PowerShell și veți primi în cele din urmă un prompt, valoarea atribuită de ultimul profil, CurrentUserCurrentHost, deoarece fiecare profil procesat succesiv va suprascrie acea variabilă cu valoarea sa. Un alt exemplu, care arată mai degrabă cooperare între profiluri decât contenție, ar putea fi acela de a incrementa o variabilă. Mai întâi definiți-o și inițializați-o la o valoare de pornire (de exemplu, $someVar = 0) în AllUsersAllHosts, apoi incrementați-o în fiecare dintre celelalte profiluri (de exemplu, $someVar++ sau poate $someVar += 5, în funcție de ceea ce doriți să faceți cu ea).

În ceea ce privește care dintre cele patru profiluri să fie folosit, acest lucru depinde în mare măsură de propriile nevoi: dacă folosiți un calculator dedicat (adică nu este împărțit cu nimeni altcineva), nu trebuie să vă faceți griji cu privire la profilurile „all users”. Dacă folosiți mai multe gazde, este posibil să doriți să diferențiați unele lucruri între un profil „toate gazdele” și un profil de gazdă specifică. Voi da mai multe detalii despre acest lucru mai jos în „De câte profiluri aveți nevoie?”

Variabila $Profile

Pentru a crea sau edita oricare dintre profiluri, desigur, trebuie să știți unde le găsiți. PowerShell însuși vă poate spune cu ușurință, dar poate, de asemenea, să deschidă pur și simplu unul pentru editare fără să vă deranjeze în mod explicit cu calea. Pentru a vedea calea, afișați valoarea variabilei $Profile. Aceasta dezvăluie o singură cale de fișier, care este calea către profilul CurrentUserCurrentHost. Într-o gazdă PowerShell standard, a mea arată astfel:

Rețineți că acest lucru nu face nici o afirmație cu privire la existența sau nu a fișierului, ci doar că aceasta este calea pe care trebuie să o aibă dacă există. Pentru a verifica existența, utilizați Test-Path:

Dacă profilul nu există, îl puteți crea cu ușurință:

Și dacă doriți să aveți acest lucru într-un script, puteți apoi să combinați cele de mai sus, creând fișierul doar dacă este necesar:

În cele din urmă, pentru a edita profilul, nu trebuie decât să invocați editorul preferat asupra fișierului, sau puteți folosi întotdeauna omniprezentul editor notepad:

Toate exemplele de mai sus sunt pentru profilul „implicit” (CurrentUserCurrentHost), așa cum am menționat. Dar puteți aplica toate aceleași comenzi la oricare dintre cele patru profiluri prin referință specifică; oricare dintre acestea produce același rezultat:

Substituiți oricare dintre celelalte trei nume de proprietăți ale profilului pentru a accesa unul dintre profilurile care nu sunt predefinite.

Numele fișierelor de profil & Locații

Secțiunea anterioară a explicat cum să editați oricare dintre profilurile dvs. fără să știți de fapt unde se află în sistemul de fișiere, dar sunteți un programator; aveți o constrângere înnăscută de a ști unde se ascund! Tabelul arată calea fiecăruia dintre ele. ( HostId este un spațiu rezervat, explicat imediat.)

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

Revizuind locațiile, este simplu de înțeles convențiile de denumire. Profilurile la nivel de sistem – cele pentru toți utilizatorii – se află în directorul de sistem indicat de $PsHome. Profilurile la nivel de utilizator se află în directorul principal al fiecărui utilizator. Singurul punct care necesită explicații este HostId indicat pentru profilurile specifice gazdei din tabel. Din păcate, acest id de gazdă nu are nicio asemănare directă cu descrierea gazdei și nici cu proprietatea $Host.Name! Modalitatea de a descoperi HostId este pur și simplu să se afișeze valoarea variabilei $Profile, deoarece aceasta face parte din calea de acces. Pentru comoditate, iată valorile HostId pentru cele mai frecvente gazde:

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

Câte profiluri aveți nevoie?

Care sistem Windows standard are două profiluri pentru gazda PowerShell standard, două pentru gazda PowerShell ISE și două pentru toate gazdele – șase în total, ca un minim. Adăugați managerul de pachete VS pe care l-am arătat, mai sunt încă două. Adăugați și alte IDE-uri PowerShell – încă două pentru fiecare. Cum gestionați atât de multe profiluri?

Interpretând doctrina oficială MSDN ( about_profiles) luați în considerare o soluție tripartită.

• În primul rând, puneți lucrurile cu adevărat comune în AllUsersAllHost.
• În al doilea rând, dacă există anumite particularități la anumite gazde, folosiți AllUsersCurrentHost pentru acele gazde răuvoitoare.
• În cele din urmă, lăsați fiecare utilizator să își gestioneze propriile preferințe și setări în profiluri specifice utilizatorului.

Dar, din nou, ar putea exista multe profiluri diferite pentru „gazda curentă”, atât la nivel de sistem, cât și la nivel de utilizator. O bună referință, în timp ce vă gândiți la alegerile dvs. aici, este postarea lui Ed Wilson (The Scripting Guy) Deciding Between One or Multiple PowerShell Profiles. El include acolo o listă de avantaje și dezavantaje pentru a alege între un profil și mai multe profiluri. Dar, pentru mine, avantajele unui singur profil depășesc cu mult avantajele profilurilor multiple. Este nevoie de ceva mai multă muncă pentru a-l configura, dar puteți ține cont în continuare de diferențele specifice fiecărei gazde, având totul într-un singur loc, ceea ce îl face mult mai simplu de întreținut în timp.

Majoritatea lucrurilor din profilul dvs. vor fi probabil comune pentru orice gazdă, așa că utilizarea unui singur profil înseamnă că orice modificări pe parcurs se vor face exact într-un singur fișier. Pentru lucrurile care diferă între gazde, includeți doar o secțiune specifică fiecărei gazde care vă interesează. Al meu include ceva de genul acesta:

Observați cum identific gazda curentă cu $Host.Name apoi execut selectiv codul. Vedeți exemplele de mai sus pentru gazda PowerShell standard, precum și pentru gazda PowerShell ISE. Pentru prima, se încarcă extensia PSReadline, care funcționează numai în gazda PowerShell. Pentru cea de-a doua, se încarcă PsISEProjectExplorer și modulul ISE Steroids, ambele putând funcționa numai în mediul ISE.

În cele din urmă, dacă folosiți Git și programul de instalare special pe care l-ați utilizat a creat pentru dumneavoastră o gazdă Git PowerShell, rețineți că aceasta nu poate fi distinsă de gazda PowerShell standard prin $Host.Name. În schimb, am identificat o variabilă definită în mod unic, $env:github_shell, care este prezentă doar în gazda cu aromă Git.

Ce să puneți în profilul dumneavoastră

Răspunsul la această întrebare depinde de nevoile dumneavoastră individuale, așa că trebuie să fie foarte abstract: puneți în profilul dumneavoastră ceea ce puteți folosi pentru a fi mai productiv. Prin urmare, nu există un răspuns unic la această întrebare, dar cu siguranță vă pot oferi câteva sugestii pentru a vă da frâu liber creativității. Tocmai ați văzut mai sus câteva exemple de import de module terțe pentru a adăuga funcționalitate la gazda dată. În afară de importurile de module, următoarele secțiuni oferă doar câteva idei pentru a vă face să vă gândiți la ceea ce ați putea dori să introduceți acolo. De asemenea, aruncați o privire la Ce se află în fișierul PowerShell `profile.ps1`? (pe StackOverflow) pentru mult mai multe exemple.

Aliases

Multe cmdlet-uri PowerShell încorporate au alias-uri; unele au mai multe alias-uri. Puteți, de exemplu, să folosiți ls sau dir sau gci în loc să tastați Get-ChildItem. Pentru cele pe care le utilizați în mod regulat și care nu oferă alias-uri (sau pentru propriile funcții și cmdlet-uri personalizate) puteți crea propriile alias-uri cu Set-Alias. este adecvat dacă doriți doar să abreviați numele cmdletului sau al funcției. Dar, uneori, s-ar putea să doriți ca un alias să includă, de exemplu, un nume de cmdlet plus un parametru pe care aveți tendința să îl utilizați întotdeauna. Pentru acestea, puteți emula un alias cu o funcție simplă. Pentru a ilustra, luați în considerare cmdlet Import-Module. Îl folosesc frecvent și prefer ca toți cmdlet-urile mele de utilizare frecventă să folosească doar prima literă a fiecărei componente. Aceasta setează aliasul im pentru a face acest lucru:

Dar, fiind un dezvoltator, am nevoie să folosesc frecvent și Import-Module cu comutatorul -Force. Așa că, pentru asta, trebuie să recurg la o funcție. Pentru convenția mea de denumire, adaug prima literă a comutatorului, deci imf aici:

Apoi pot folosi, de exemplu, im foobar pentru a face un import de tip vanilie, sau imf foobar pentru a importa cu -Force aplicat.

Funcții simple

Funcțiile au fost doar menționate ca un mijloc de a crea pseudo-alianțe, adică, în esență, pentru a vă economisi tastarea. Dar, bineînțeles, ele nu se limitează la acest scop. S-ar putea să doriți să includeți în profilul dvs. o varietate de „one-liners” care vă economisesc atât tastarea, cât și faptul că nu trebuie să rețineți detaliile cmdlet-urilor pe care le utilizați mai rar. Repede, cum se afișează ultimele 50 de elemente din istoricul comenzilor? Nu sunteți sigur? cmdlet-ul care trebuie folosit este Get-History (are un alias standard format doar din litera h). Este ușor de reținut Get-History -Count 50 sau doar h50? Iată definiția mea pentru h50 (și un h10 aruncat doar pentru o măsură bună):

Iată o funcție mai interesantă. Cum ați putea dezvălui cmdlet-ul din spatele unui alias, calea către un executabil având în vedere doar numele programului, seturile de parametri disponibile pentru un anumit cmdlet sau conținutul unei funcții definite de utilizator? Eu folosesc acest one-liner pentru a face toate acestea (numit după comanda unix/linux care are o performanță similară):

Iată câteva rezultate ale utilizării sale:

În cele din urmă, un alt one-liner la îndemână care, din nou, funcționează ca și comanda unix/linux, raportând numele dvs. de utilizator calificat de domeniu:

Funcții complexe

Este probabil ca în cursul activității dumneavoastră să creați unele funcții utilitare care sunt mult mai implicate decât un simplu one-liner. Ați putea, desigur, să le încorporați pur și simplu în profilul dumneavoastră, dar acest lucru tinde să vă facă profilul lung și dezordonat. Dacă aveți o colecție de astfel de funcții, ați putea oricând să le organizați într-un adevărat modul PowerShell și apoi să adăugați doar un Import-Module în profilul dvs. pentru a le introduce. Pentru ceva între aceste două extreme, luați în considerare această abordare. În profilul meu am această secvență de comenzi care aduce toate scripturile din directorul meu local profile_scripts în domeniul de aplicare la pornire:

$PSScriptRoot este o variabilă de sistem standard care există doar în contextul unui script în execuție. Ea se rezolvă la $Home\Documents\WindowsPowerShell\. Astfel, directorul meu profile_scripts se află sub această cale. Orice script (cu excepția scripturilor de test) este localizat prin puncte, făcându-l vizibil în domeniul de acțiune curent de îndată ce aveți un prompt după pornire.

Realizați acțiuni

Elementele anterioare din această secțiune sunt toate pasive; ele definesc lucruri pe care le veți folosi la un moment dat după pornire. Dar puteți include și elemente active care se execută în timpul pornirii. Vă recomand cu căldură să folosiți cmdlet-ul „nu mă lăsați să mă împușc în picior”:

Limbajele care sunt slab tipizate (de ex.ex. JavaScript, PowerShell) vă oferă opțiunea de a lucra în siguranță sau nu, în timp ce limbajele puternic tipizate vă obligă, în general, să lucrați în siguranță. În principal, în condiții de siguranță înseamnă că nu vă permiteți să utilizați o variabilă înainte ca aceasta să fie declarată. Acest lucru previne ca o greșeală de tastare involuntară să vă provoace nenumărate necazuri încercând să vă dați seama de ce nu funcționează codul dumneavoastră. (Probabil, cei care lucrează cu limbaje slab tipizate cred că unii oameni ar putea considera că operarea în siguranță este o povară, așa că au făcut-o o opțiune). Pur și simplu puneți Set-PSDebug în profilul dumneavoastră. Fiți în siguranță. Vă rog.

Alte tipuri de acțiuni pe care le-ați putea pune în profilul dvs. sunt lucruri cum ar fi afișarea unor statistici, de exemplu, timpul de funcționare, spațiul pe disc sau politica de execuție PowerShell. Dacă administrați mai multe mașini, ați putea dori să vedeți detalii despre mașina în care v-ați „retras”, pentru a vă asigura că vă aflați pe cutia în care credeți că vă aflați (numele domeniului, numele calculatorului, adresa IP etc.).

Securizarea profilului dumneavoastră

Când aveți de-a face cu calculatoare, securitatea trebuie să fie întotdeauna un aspect de luat în considerare. Folosiți un firewall și un antivirus pentru a încerca să vă păstrați sistemul în siguranță. În mod similar, trebuie să luați în considerare scripturile PowerShell pe care le rulați – inclusiv propriile profiluri. PowerShell are un bun suport pentru securitate, începând cu setarea sa implicită de a nu vă permite să rulați niciun script; din start puteți utiliza doar comenzi PowerShell în mod interactiv. Trebuie să vă deschideți sistemul suficient de mult pentru a vă permite să realizați orice lucru de care aveți nevoie prin setarea politicii de execuție a computerului (consultați Set-ExecutionPolicy).

Dar imediat ce permiteți rularea scripturilor, există o șansă să rulați din greșeală un script compromis. Acest lucru nu este ceva unic pentru scripturile PowerShell în sine – orice lucru de pe computerul dumneavoastră ar putea fi compromis – doar că PowerShell vă ajută să atenuați situația. Și face acest lucru permițându-vă să setați politica de execuție la diferite niveluri de securitate în funcție de nevoile dumneavoastră. Puteți cere ca fiecare script să fie autentificat sau ca doar orice script pe care îl descărcați să fie autentificat, printre alte opțiuni. Autentificarea, în acest caz, se referă la semnarea scripturilor cu o semnătură digitală (a se vedea Set-AuthenticodeSignature), astfel încât, dacă un fișier este modificat (în mod malițios sau nu), semnătura digitală ar detecta modificarea și ar împiedica scriptul să ruleze.

Gestionarea securității pentru scripturile PowerShell (inclusiv pentru profilurile dvs.), totuși, nu este un efort trivial. (Ar fi mai mult decât dublat lungimea acestui articol!) Dar există deja o mulțime de informații bune pentru a vă ghida. V-aș recomanda să începeți cu un alt articol de aici de pe Simple-Talk, PowerShell Day-to-Day SysAdmin Tasks al lui Nicolas Prigent: Securizarea scripturilor. Există, de asemenea, câteva referințe bune în propria documentație PowerShell: about_signing oferă o bună introducere în acest subiect; New-SelfSignedCertificate vă permite să vă creați propriile certificate autofirmate, iar Get-ChildItem for Certificate dezvăluie diferențele puțin cunoscute din Get-ChildItem atunci când faceți referire la magazinul de certificate. Microsoft oferă o referință veche, dar încă utilă, privind cele mai bune practici de semnare a codurilor. Iar cartea lui Geoff Bard Signing PowerShell Scripts merită și ea o privire.

Get That Profile Out of the Way!

Acum știți cum să vă configurați profilul, de ce este util, ce să faceți cu el și cum să îl protejați. Dar, ca orice superputere, trebuie să fiți conștienți de partea sa întunecată. Ei bine, nu atât de mult o latură întunecată în sine, ci faptul că există momente în care pur și simplu nu doriți ca profilul (profilurile) dvs. să vă stea în cale. Sau, mai emoționant, profilurile altor persoane.

Există o varietate de situații în care ați putea dori să executați efectiv powershell.exe, fie cu o comandă literală, fie cu un fișier script de executat. Iată doar un exemplu: să spunem că ați creat un script PowerShell pe care doriți să îl partajați cu un coleg. Spre deosebire de fișierele batch, nu puteți pur și simplu să dați dublu clic pe un script PowerShell pentru a-l executa; acest lucru face parte din modus operandi-ul de securitate al PowerShell pentru a vă păstra sistemul în siguranță. Dar acest lucru este ușor de ocolit (nu că aș recomanda acest lucru!) prin crearea unei comenzi rapide Windows standard care să vizeze powershell.exe cu fișierul script PowerShell ca parametru.

O altă utilizare, poate mai legitimă, ar fi să executați un script sau o comandă PowerShell în cadrul unui fișier de construcție. Deoarece MSBuild nu știe în mod înnăscut cum să ruleze scripturi PowerShell, de obicei ați executa un script furnizându-l ca argument pentru powershell.exe.

De fiecare dată când executați powershell.exe, totuși, deschideți o nouă gazdă PowerShell. Și ce se întâmplă atunci când deschideți o gazdă? Se execută oricare (sau toate) dintre cele patru profiluri ale dumneavoastră! Dar aproape de fiecare dată când deschideți o gazdă prin invocarea directă a powershell.exe nu doriți ca profilurile dvs. să ruleze, nici pentru cheltuielile generale, nici pentru posibilele conflicte care ar putea apărea. Țineți cont de faptul că, dacă altcineva rulează un build în care ați introdus o comandă pentru a rula powershell.exe, este profilul său care va fi rulat pe mașina sa, iar dumneavoastră nu aveți nicio noțiune despre ce ar putea să se ascundă acolo. Mai mult decât atât, nu doriți să depindeți de ceva dintr-un profil, deoarece prima dată când cineva care nu cunoaște această dependență va rula compilarea, aceasta va eșua (posibil în mod misterios). Așadar, cel mai sigur este să adoptați pur și simplu cea mai bună practică de a ignora întotdeauna profilurile atunci când apelați powershell.exe. (Nu vreau să spun că ar trebui să le ignorați, ci mai degrabă că ar trebui să-i spuneți lui PowerShell să le ignore, desigur!

Așa că, după toată această construcție plină de suspans, deznodământul poate fi un pic anticlimatizat: adăugați pur și simplu un -NoProfile ca parametru la powershell.exe.

Concluzie

Profilul PowerShell este prietenul dumneavoastră. Cu foaia de parcurs prezentată în acest articol, ați văzut tipurile de profiluri care vă sunt disponibile și le puteți selecta pe cele care vor funcționa pentru dumneavoastră. Sau puteți alege să utilizați un singur profil, distingând orice elemente specifice gazdei, după cum este necesar. Profilul este un instrument simplu, dar puternic, care vă stă la dispoziție, nu este deloc complicat de utilizat, iar utilizările sale sunt limitate doar de imaginația dumneavoastră. Cam singurul dezavantaj este tot timpul pe care îl veți petrece acum căutând lucruri utile și inteligente pe care să le adăugați la profilul dumneavoastră. (Am menționat că ar trebui să vă gândiți la includerea modulului Go-Shell…?)

.