În scripturile batch, modificările la variabilele de mediu au un impact global asupra sesiunii curente în mod implicit. Pentru PowerShell, exact opusul este adevărat, deoarece scopurile sunt folosite pentru a izola modificările unui script. Aici, vom explora modul în care domeniile afectează scripturile PowerShell și cum să lucreze în și în jurul lor.
În PowerShell, un "domeniu" se referă la mediul actual în care funcționează un script sau un shell de comandă. Scopurile sunt folosite pentru a proteja anumite obiecte din mediul înconjurător de modificarea neintenționată de scripturi sau funcții. În mod special, următoarele lucruri sunt protejate de modificări de comenzi care rulează dintr-un alt domeniu de aplicare, cu excepția cazului în care se specifică altfel parametrii din acele comenzi:
Domenii noi sunt create ori de câte ori executați un script sau o funcție sau când creați o nouă sesiune sau instanță a PowerShell. Scopurile create prin rularea de scripturi și funcții au o relație "părinte / copil" cu domeniul de aplicare din care au fost create. Există câteva domenii care au înțelesuri deosebit de speciale și pot fi accesate prin nume:
Scopurile pot fi, de asemenea, numite în număr în anumite comenzi, unde domeniul de aplicare curent este referit la zero, iar strămoșii săi sunt menționați prin creșterea numărului întreg. De exemplu, în cadrul unui script executat din domeniul global, domeniul Script ar fi 0, iar domeniul de aplicare global va fi 1. Un domeniu care a fost încorporat în continuare în sfera Script, cum ar fi o funcție, se referă la domeniul global ca 2 Numerele negative nu vor funcționa pentru a referenți scopurile copilului - motivul pentru care va fi evident în scurt timp.
Așa cum am menționat mai devreme, comenzile executate într-un singur domeniu de aplicare nu vor afecta lucrurile într-un alt domeniu, dacă nu li se va spune în mod expres acest lucru. De exemplu, dacă $ MyVar există în domeniul Global și un script rulează o comandă pentru a seta $ MyVar la o valoare diferită, versiunea globală a lui $ MyVar va rămâne neschimbată în timp ce o copie a lui $ MyVar este plasată în domeniul Script cu noua valoare. Dacă un $ MyVar nu există, un script îl va crea în scop Script în mod implicit - nu în domeniul Global. Acest lucru este important de reținut în timp ce aflați despre relația reală părinte / copil între domenii.
Relația mamă / copil a domeniilor în PowerShell este una. Comenzile pot vedea și pot modifica opțional domeniul de aplicare actual, părintele său și toate domeniile de mai sus. Cu toate acestea, ei nu pot vedea sau modifica lucrurile la nici un copil din domeniul de aplicare actual. Acest lucru se datorează în primul rând faptului că, odată ce v-ați mutat într-un scop parental, domeniul copilului a fost deja distrus pentru că și-a îndeplinit scopul. De exemplu, de ce ar trebui să vedeți sau să modificați o variabilă în domeniul Script, din domeniul global, după terminarea scriptului? Există o mulțime de cazuri în care aveți nevoie ca schimbările unui script sau ale funcției să persiste dincolo de încheierea acestuia, dar nu atât de multe în cazul în care va trebui să faceți modificări obiectelor din sfera de aplicare a scriptului sau a funcției înainte sau după rularea acestuia. (De obicei, astfel de lucruri vor fi tratate, oricum, ca parte a scriptului sau a funcției.)
Desigur, care sunt regulile fără excepții? O excepție de la cele de mai sus sunt domeniile private. Obiectele din domeniul privat sunt accesibile numai comenzilor care se execută în domeniul de aplicare din care au fost create. O altă excepție importantă sunt articolele care au proprietatea AllScope. Acestea sunt variabile și aliasuri speciale pentru care o schimbare în orice domeniu de aplicare va afecta toate domeniile. Următoarele comenzi vă vor arăta care variabile și aliasuri au proprietatea AllScope:
Get-Variable | Unde-Obiect $ _ Opțiuni -match 'AllScope' Get-Alias | Unde-Obiect $ _ Opțiuni -match "AllScope")
Pentru prima noastră viziune asupra domeniilor în acțiune, vom începe într-o sesiune PowerShell unde variabila $ MyVar a fost setată la un șir, "Eu sunt o variabilă globală!", Din linia de comandă. Apoi, următorul script va fi rulat dintr-un fișier numit Scope-Demo.ps1:
Function FunctionScope 'Schimbarea $ MyVar cu o functie.' $ MyVar = 'Am fost stabilit de o funcție!' "MyVar spune $ MyVar" "Verificarea valorii curente $ MyVar". "MyVar spune $ MyVar" "Schimbarea $ MyVar prin script." $ MyVar = 'M-am pus de un scenariu!' "MyVar spune $ MyVar" "FunctionScope" Verificarea valorii finale a MyVar înainte de ieșirea din script. " "MyVar spune $ MyVar" "
Dacă script-urile PowerShell au funcționat la fel ca scripturile batch, ne-am aștepta ca valul de $ MyVar (sau% MyVar% în sintaxa lotului) să se schimbe de la 'Sunt o variabilă globală!', La 'Am setat de un script!' , și în cele din urmă la "M-am pus de o funcție!" unde ar rămâne până când se va schimba în mod explicit din nou sau dacă sesiunea nu va mai fi terminată.Cu toate acestea, vedeți ce se întâmplă de fapt aici, pe măsură ce trecem prin fiecare domeniu - în special, după ce funcția FunctionScope și-a finalizat activitatea și verificăm din nou variabila din scenariu și mai târziu domeniul global.
După cum puteți vedea, variabila părea să se schimbe pe măsură ce ne-am mutat prin script deoarece, până când funcția FunctionScope a fost finalizată, verificam variabila din același domeniu în care a fost modificată ultima dată. După ce a fost efectuat funcția FunctionScope, ne-am mutat înapoi în sfera scenariului în care $ MyVar a rămas neatins de această funcție. Apoi, când scenariul sa terminat, am revenit în domeniul global unde nu fusese modificat deloc.
Deci, toate acestea sunt bune și bune pentru a vă ajuta să păstrați de la aplicarea accidentală a modificărilor la mediul înconjurător, dincolo de scenariile și funcțiile dvs., dar dacă, de fapt, doriți să faceți astfel de modificări? Există o sintaxă specială și destul de simplă pentru crearea și modificarea obiectelor dincolo de domeniul de aplicare local. Tocmai ați pus numele de domeniu la începutul numelui variabilei și ați pus un punct între numele domeniului și numele variabilei. Asa:
$ globală: MyVar $ script: MyVar $ local: MyVar
Puteți utiliza acești modificatori atât la vizualizarea, cât și la setarea variabilelor. Să vedem ce se întâmplă cu acest scenariu demonstrativ:
Funcția FunctionScope "Schimbarea $ MyVar în domeniul de funcții locale ..." $ local: MyVar = "Acesta este MyVar în domeniul de aplicare al funcției locale" "Schimbarea $ MyVar în sfera scenariului ..." $ script: MyVar = 'MyVar obișnuia să fie "$ global: MyVar = 'MyVar a fost setat în domeniul global. Acum, setat de o funcție. "Verificarea $ MyVar în fiecare domeniu de aplicare ..." "Local: $ local: MyVar" "Script: $ script: MyVar" "Global: $ global: MyVar" " Obținerea valorii curente $ MyVar. "MyVar spune $ MyVar" "Schimbarea $ MyVar prin script." $ MyVar = 'M-am pus de un scenariu!' "MyVar spune că $ MyVar" FunctionScope "verifică $ MyVar din domeniul de aplicare al scenariului înainte de ieșire." "MyVar spune $ MyVar" "
Ca și înainte, vom începe prin stabilirea variabilei în domeniul global și se va încheia cu verificarea rezultatului finalizării globale finale.
Aici puteți vedea că funcția FunctionScope a reușit să schimbe variabila în domeniul Script și să aibă modificările persistă după ce a fost terminată. De asemenea, schimbarea la variabila din domeniul Global a persistat chiar și după terminarea scenariului. Acest lucru poate fi util în special dacă trebuie să modificați în mod variabil variabilele într-un script sau în domeniul global, folosind același cod - definiți doar o funcție sau un script scrise pentru a modifica variabila unde și cum aveți nevoie de ea și apelați la aceasta ori de câte ori aceste schimbări sunt necesare.
Așa cum am menționat mai devreme, numerele de domeniu pot fi de asemenea utilizate în anumite comenzi pentru a modifica variabila la diferite niveluri în raport cu domeniul local. Iată același script utilizat în cel de-al doilea exemplu de mai sus, dar cu funcția modificată pentru a utiliza comenzile Get-Variable și Set-Variable cu numere de domeniu în loc de a face referire directă la variabila cu domeniile numite:
Function FunctionScope "Schimbarea $ MyVar in domeniul 0, relativ la FunctionScope ..." Set-Variable MyVar "Aceasta este MyVar in domeniul 0." -Scope 0 "Schimbarea $ MyVar in domeniul 1, relativ la FunctionScope ... Set-Variable MyVar "MyVar a fost schimbat în domeniul 1, de la o funcție." -Scopul 1 "Schimbarea lui $ MyVar în domeniul 2, relativ la Functionscope ..." Set-Variable MyVar "MyVar a fost schimbat în domeniul 2, dintr-o funcție. -Scopul 2 "Verificarea $ MyVar în fiecare domeniu de aplicare ..." Domeniul de aplicare 0: "Obțineți variabila MyVar -Scope 0 -ValueOnly" Domeniul de aplicare 1: "Obțineți variabila MyVar -Scopul 1 -ValueOnly" Domeniul 2: "GetVariable MyVar -Scope 2 -ValueOnly "" Obținerea valorii curente a $ MyVar. " "MyVar spune $ MyVar" "Schimbarea $ MyVar prin script." $ MyVar = 'M-am pus de un scenariu!' "MyVar spune că $ MyVar" FunctionScope "verifică $ MyVar din domeniul de aplicare al scenariului înainte de ieșire." "MyVar spune $ MyVar" "
Similar cu înainte, putem vedea aici cum comenzile dintr-un domeniu de aplicare pot modifica obiectele din domeniul său de aplicare.
Există încă mult mai multe care pot fi făcute cu scopuri decât se pot potrivi în acest articol. Scopurile afectează mai mult decât variabilele și mai sunt multe de învățat despre domeniile private și variabilele AllScope. Pentru informații mai utile, puteți executa următoarea comandă din PowerShell:
Obțineți-Help about_scopes
Același fișier de ajutor este, de asemenea, disponibil în TechNet.
Scopul creditului imagine: spadassin pe openclipart
