In batch-scripts hebben wijzigingen in omgevingsvariabelen standaard een wereldwijde impact op de huidige sessie. Voor PowerShell geldt precies het tegenovergestelde, omdat scopes worden gebruikt om de wijzigingen van een script te isoleren. Hier zullen we onderzoeken hoe scopes van invloed zijn op PowerShell-scripts en hoe u in en om hen heen kunt werken.
In PowerShell verwijst een "scope" naar de huidige omgeving waarin een script of opdrachtshell wordt gebruikt werkt. Scopes worden gebruikt om te voorkomen dat bepaalde objecten in de omgeving onbedoeld worden gewijzigd door scripts of functies. In het bijzonder worden de volgende dingen beschermd tegen wijziging door opdrachten die worden uitgevoerd vanuit een ander bereik, tenzij anders aangegeven door parameters in die opdrachten:
Nieuwe bereiken worden gemaakt wanneer u een script of functie uitvoert, of wanneer u een nieuwe sessie of exemplaar van PowerShell maakt. Scopes die zijn gemaakt door scripts en functies uit te voeren, hebben een "ouder / kind" -relatie met het bereik waaruit ze zijn gemaakt. Er zijn een aantal scopes met een bijzonder speciale betekenis en deze zijn toegankelijk op naam:
Scopes kunnen ook worden aangeduid met nummer in bepaalde opdrachten, waarbij de huidige scope wordt aangeduid als nul en waarnaar de voorouders worden verwezen door het verhogen van gehele getallen. Binnen een script dat wordt uitgevoerd vanuit het algemene bereik, zou het scriptbereik bijvoorbeeld 0 zijn en zou het algemene bereik 1 zijn. Een bereik dat verder is genest binnen het scriptbereik, zoals een functie, zou verwijzen naar het algemene bereik als 2 Negatieve getallen zullen echter niet werken om te verwijzen naar kindscopes - de reden hiervoor zal snel duidelijk worden.
Zoals eerder vermeld, zullen commando's die binnen één scope worden uitgevoerd geen invloed hebben op dingen in een andere scope tenzij specifiek verteld om dit te doen. Als bijvoorbeeld $ MyVar in de globale scope bestaat en een script een opdracht uitvoert om $ MyVar op een andere waarde in te stellen, blijft de algemene versie van $ MyVar ongewijzigd, terwijl een kopie van $ MyVar in de scriptscope wordt geplaatst met de nieuwe waarde. Als een $ MyVar niet bestaat, maakt een script dit standaard binnen het Script-bereik - niet in de globale scope. Dit is belangrijk om te onthouden wanneer u meer te weten komt over de feitelijke ouder / kindrelatie tussen scopes.
De ouder / kindrelatie van scopes in PowerShell is one-way. Opdrachten kunnen de huidige scope, het bovenliggende bereik en eventuele scopes daarboven bekijken en optioneel wijzigen. Ze kunnen echter geen dingen zien of wijzigen in kinderen van het huidige bereik. Dit komt vooral omdat, als je eenmaal bent verhuisd naar een bovenliggende scope, het onderliggende bereik al is vernietigd omdat het zijn doel heeft vervuld. Waarom zou u bijvoorbeeld een variabele in het Script-bereik moeten zien of wijzigen, van de globale scope, nadat het script is beëindigd? Er zijn veel gevallen waarin u de wijzigingen van een script of functie nodig hebt om verder te gaan dan het is voltooid, maar niet zo veel waar u wijzigingen moet aanbrengen aan objecten binnen het bereik van het script of functie vóór of na de uitvoering. (Meestal worden zulke dingen als onderdeel van het script of de functie zelf verwerkt.)
Wat zijn natuurlijk regels zonder uitzonderingen? Een uitzondering op het bovenstaande zijn privé-scopes. Objecten in de privéscopes zijn alleen toegankelijk voor opdrachten die worden uitgevoerd binnen het bereik van waaruit ze zijn gemaakt. Een andere belangrijke uitzondering zijn items met de eigenschap AllScope. Dit zijn speciale variabelen en aliassen waarvoor een wijziging in een bereik van invloed is op alle scopes. De volgende opdrachten laten zien welke variabelen en aliassen de AllScope-eigenschap hebben:
Get-Variable | Where-Object {$ _. Opties -match 'AllScope'} Get-alias | Where-Object {$ _. Opties -match 'AllScope')
Voor onze eerste blik op scopes in actie, beginnen we in een PowerShell-sessie waarin de variabele $ MyVar is ingesteld naar een string, 'Ik ben een globale variabele!', vanaf de opdrachtregel. Vervolgens wordt het volgende script uitgevoerd vanuit een bestand met de naam Scope-Demo.ps1:
Function FunctionScope {'Wijzigen van $ MyVar met een functie.' $ MyVar = 'Ik ben ingesteld door een functie!' "MyVar zegt $ MyVar"} "Huidige waarde van $ MyVar controleren." "MyVar zegt $ MyVar" "$ MyVar per script wijzigen." $ MyVar = 'Ik ben door een script ingesteld!' "MyVar zegt $ MyVar" "FunctionScope" De definitieve waarde van MyVar controleren voordat het script wordt afgesloten. ' "MyVar zegt $ MyVar" "
Als PowerShell-scripts hetzelfde werkten als batch-scripts, verwachten we dat het dal van $ MyVar (of% MyVar% in batch-syntaxis) verandert van 'Ik ben een globale variabele!', naar 'Ik ben door een script ingesteld!' en uiteindelijk tot 'Ik ben door een functie ingesteld!' waar het zou blijven totdat het expliciet opnieuw wordt gewijzigd of de sessie wordt beëindigd, maar kijk wat er hier gebeurt terwijl we door elk van de scopes gaan - met name nadat de functie FunctionScope zijn werk heeft voltooid en we de variabele opnieuw controleren vanuit het script , en later de globale scope.
Zoals u ziet, leek de variabele te veranderen toen we door het script gingen omdat, tot de functie FunctionScope voltooid was, we de variabele controleerden vanuit dezelfde scope als de laatste was Nadat FunctionScope echter was voltooid, keerden we terug naar het Script-bereik waar $ MyVar onaangeroerd bleef door de functie. Toen het script werd beëindigd, kwamen we weer terug in de globale scope waar het helemaal niet was gewijzigd.
Dit is dus allemaal goed en wel om te voorkomen dat u per ongeluk wijzigingen in de omgeving toepast die verder gaan dan uw scripts en functies, maar wat als u die wijziging daadwerkelijk wilt aanbrengen aties? Er is een speciale en vrij eenvoudige syntaxis voor het maken en wijzigen van objecten buiten het lokale bereik. Plaats de naam van het bereik aan het begin van de naam van de variabele en plaats een dubbele punt tussen de bereik- en variabelenamen. Vind dit leuk:
$ global: MyVar $ script: MyVar $ local: MyVar
U kunt deze modifiers zowel gebruiken bij het bekijken en instellen van variabelen. Laten we eens kijken wat er gebeurt met dit demonstratiescript:
Functie FunctionScope {"Wijzigen van $ MyVar in het lokale functiebereik ... '$ local: MyVar =" Dit is MyVar in het lokale bereik van de functie. "' Wijzigen van $ MyVar in het scriptbereik ... '$ script: MyVar =' MyVar werd vroeger ingesteld door een script. Nu ingesteld door een functie. "Wijzigen van $ MyVar in de globale scope ... '$ global: MyVar =' MyVar werd ingesteld in de globale scope. Nu ingesteld door een functie. "$ MyVar controleren in elk bereik ... '" Lokaal: $ local: MyVar " Script: $ script: MyVar " Globaal: $ global: MyVar "} "Huidige waarde van $ MyVar ophalen." "MyVar zegt $ MyVar" "$ MyVar per script wijzigen." $ MyVar = 'Ik ben door een script ingesteld!' "MyVar zegt $ MyVar" FunctionScope 'Checking $ MyVar from script scope before exit.' "MyVar zegt $ MyVar" "
Zoals eerder, beginnen we met het instellen van de variabele in de globale scope en eindigen met het controleren van het uiteindelijke mondiale bereikresultaat.
Hier kunt u zien dat FunctionScope in staat was om de variabele te veranderen in de Script-scope en houden de wijzigingen aan nadat deze zijn voltooid. Ook bleef de wijziging van de variabele in de globale scope bestaan nadat het script was afgesloten. Dit kan met name handig zijn als u variabelen binnen een script herhaaldelijk moet wijzigen , of binnen de globale scope, met dezelfde code - je definieert alleen een functie of script dat geschreven is om de variabele waar en hoe je het nodig hebt te wijzigen, en roept die op wanneer die veranderingen nodig zijn.
Zoals eerder vermeld, scope-aantallen kunnen ook worden gebruikt in bepaalde opdrachten om de variabele op verschillende niveaus te wijzigen in relatie tot de lokale scope.Hier is hetzelfde script gebruikt in het tweede voorbeeld hierboven, maar met de functie gewijzigd om de opdrachten Get-Variable en Set-Variable te gebruiken met bereik nummer in plaats van rechtstreeks naar de variabele met benoemde scopes te verwijzen:
Functie FunctieScope {"Wijzigen $ MyVar in scope 0, ten opzichte van FunctionScope ... 'Set-Variable MyVar" Dit is MyVar binnen het bereik van de functie 0. "-Scope 0' Wijzigen van $ MyVar in scope 1, ten opzichte van FunctionScope ... 'Set-Variable MyVar 'MyVar is in scope 1 veranderd, vanuit een functie.' -Scope 1 'Changing MyVar in scope 2, tov Functionscope ...' Set-Variable MyVar 'MyVar is in scope 2 veranderd, vanuit een functie.' -Scope 2 "Controle van $ MyVar in elk bereik ..." Scope 0: 'Get-Variable MyVar -Scope 0 -ValueOnly' Scope 1: 'Get-Variable MyVar -Scope 1 -ValueOnly' Scope 2: 'Get-Variable MyVar -Scope 2 -ValueOnly "}" Huidige waarde krijgen van $ MyVar. ' "MyVar zegt $ MyVar" "$ MyVar per script wijzigen." $ MyVar = 'Ik ben door een script ingesteld!' "MyVar zegt $ MyVar" FunctionScope 'Checking $ MyVar from script scope before exit.' "MyVar zegt $ MyVar" "
Zoals eerder, kunnen we hier zien hoe opdrachten in een scope objecten in de bovenliggende scope kunnen wijzigen.
Er is nog veel meer dat kan worden gedaan met scopes dan Dit bereik is van invloed op meer dan alleen variabelen en er is nog meer te leren over privé-scopes en de AllScope-variabelen.Voor meer nuttige informatie kunt u de volgende opdracht uitvoeren vanuit PowerShell:
Get-Help about_scopes
Hetzelfde helpbestand is ook beschikbaar op TechNet.
Scope image credit: spadassin on openclipart
Een stijl zoeken die u niet ziet op het tabblad Home in Microsoft Word
Microsoft Word toont standaard niet alle ingebouwde stijlen op het tabblad Start of op de startpagina. Deelvenster Stijlen. Dus, wat als u een stijl wilt gebruiken die u niet ziet? GERELATEERD: Mastering Styles en Document Themes Styles besparen u veel tijd en zorgen voor consistentie bij het formatteren van uw documenten.
5 Tips om betere foto's te maken met de camera van uw smartphone
Point-and-shoot camera's zijn de weg van de dodo afgegaan. Natuurlijk kunnen ervaren fotografen zich tot DSLR-camera's wenden, maar de meesten van ons gaan gewoon met de camera rond op onze smartphone. Smartphone-camera's worden elk jaar beter, maar sommige dingen veranderen nooit. Deze tips helpen je om betere foto's te maken.