I batch scripts har ændringer til miljøvariabler som standard en global indvirkning på den aktuelle session. For PowerShell er det nøjagtige modsatte sandt, fordi scopes bruges til at isolere et scripts modifikationer. Her undersøger vi, hvordan scopes påvirker PowerShell-scripts og hvordan man arbejder i og omkring dem.
I PowerShell refererer et "omfang" til det nuværende miljø, hvor et script eller kommando skal er i drift. Områder bruges til at beskytte visse genstande i miljøet fra at blive utilsigtet ændret af skrifter eller funktioner. Specielt er følgende ting beskyttet mod modifikation af kommandoer, der løber fra et andet omfang, medmindre andet er angivet af parametre i disse kommandoer:
Nye scopes oprettes, når du kører et script eller en funktion, eller når du opretter en ny session eller et eksempel på PowerShell. Områder oprettet ved at køre scripts og funktioner har et "forældre / barn" forhold med det omfang, hvorfra de blev oprettet. Der er et par områder, der har særlig særlige betydninger, og kan fås ved navn:
Scopes kan også henvises til med nummer i bestemte kommandoer, hvor det nuværende anvendelsesområde refereres til som nul, og dets forfædre refereres ved at øge heltal. For eksempel inden for et script, der løber fra det globale anvendelsesområde, vil Script-omfanget være 0, og det globale omfang ville være 1. Et omfang, der blev yderligere indlejret i Script-anvendelsesområdet, som en funktion, ville henvise til det globale omfang som 2 . Negative tal vil dog ikke fungere for at henvise til børnescopes. Årsagen til dette bliver tydeligt inden for kort tid.
Som tidligere nævnt vil kommandoer, der udføres inden for et anvendelsesområde, ikke påvirke tingene i et andet omfang, medmindre det specifikt er angivet for at gøre det. Hvis f.eks. $ MyVar eksisterer i det globale omfang, og et script kører en kommando for at indstille $ MyVar til en anden værdi, forbliver den globale version af $ MyVar uændret, mens en kopi af $ MyVar er placeret i Script-omfanget med den nye værdi. Hvis en $ MyVar ikke eksisterer, vil et script skabe det inden for Script-anvendelsesområdet som standard - ikke i det globale omfang. Dette er vigtigt at huske, da du lærer om det egentlige forældre / barnforhold mellem scopes.
Forholdet mellem forældre og børn i scopes i PowerShell er envejs. Kommandoer kan se ind i og eventuelt ændre det nuværende omfang, dets forælder og enhver rækkevidde ovenfor. Men de kan ikke se eller ændre tingene i nogen børn i det nuværende omfang. Dette skyldes først og fremmest, at når du har flyttet ind i et overordnede anvendelsesområde, er barnets omfang allerede ødelagt, fordi det har opfyldt dets formål. Hvorfor skal du for eksempel se eller ændre en variabel i Script-omfanget, fra det globale omfang, efter at scriptet er afsluttet? Der er masser af tilfælde, hvor du har brug for et scripts eller funktionens ændringer for at fortsætte ud over dets gennemførelse, men ikke så mange, hvor du skal foretage ændringer i objekter inden for scriptets eller funktionens omfang før eller efter det køres. (Normalt vil sådanne ting blive håndteret som en del af scriptet eller funktionen alligevel.)
Hvad er reglerne uden undtagelser? En undtagelse til ovenstående er private scopes. Objekter i de private scopes er kun tilgængelige for kommandoer, der kører i det område, hvorfra de blev oprettet. En anden vigtig undtagelse er varer, der har AllScope-ejendommen. Disse er specielle variabler og aliaser, for hvilke en ændring i ethvert anvendelsesområde vil påvirke alle anvendelsesområder. Følgende kommandoer viser dig hvilke variabler og aliaser, der har AllScope-egenskaben:
Get-Variable | Hvor-objekt {$ _. Indstillinger -match 'AllScope'} Get-Alias | Hvor-objekt {$ _. Options -match 'AllScope')
For vores første kig på scopes in action, skal vi starte i en PowerShell-session, hvor variablen $ MyVar er indstillet til en streng, 'Jeg er en global variabel!', fra kommandolinjen. Derefter køres følgende script fra en fil kaldet Scope-Demo.ps1:
Funktion FunctionScope {'Ændring $ MyVar med en funktion.' $ MyVar = 'Jeg blev sat af en funktion!' "MyVar siger $ MyVar"} "Kontrollerer nuværende værdi af $ MyVar." "MyVar siger $ MyVar" "Ændring af $ MyVar efter script." $ MyVar = 'Jeg blev sat af et script!' "MyVar siger $ MyVar" "FunctionScope" Kontrollerer slutværdien af MyVar før script exit. " "MyVar siger $ MyVar" "
Hvis PowerShell-scripts fungerede som batch scripts, ville vi forvente, at valget af $ MyVar (eller% MyVar% i batchsyntax) ændres fra 'Jeg er en global variabel!' til 'Jeg blev sat af et script!', og endelig til 'Jeg blev sat af en funktion!' hvor det vil forblive, indtil det eksplicit ændres igen eller sessionen afsluttes. Se dog hvad der sker her, når vi bevæger os gennem hver af de forskellige områder - især efter at FunctionScope-funktionen har gennemført sit arbejde, og vi kontrollerer variablen igen fra Scriptet , og senere den globale rækkevidde.
Som du kan se, var variablen tilsyneladende ændret, da vi flyttede gennem scriptet, fordi vi indtil funktionen FunctionScope var færdig, kontrollerede vi variablen inden for samme omfang som det var sidste ændret. Efter at FunctionScope blev gjort, flyttede vi tilbage til Script-anvendelsesområdet, hvor $ MyVar blev uberørt af funktionen. Da scriptet sluttede, kom vi tilbage til det globale omfang, hvor det ikke var blevet ændret overhovedet.
Så det er alt godt og godt at hjælpe dig med at undgå uheldige ændringer i miljøet ud over dine scripts og funktioner, men hvad hvis du rent faktisk ønsker at lave en sådan modifikation tioner? Der er en speciel og ret simpel syntaks for at oprette og ændre objekter ud over lokalområdet. Du sætter bare rækkeviddenavnet i starten af variablenavnet og sætter et kolon mellem rækkevidde og variabelnavne. Som dette:
$ global: MyVar $ script: MyVar $ local: MyVar
Du kan bruge disse modifikatorer både når du ser og indstiller variabler. Lad os se hvad der sker med dette demonstrationsskript:
Funktion FunctionScope {"Ændring af $ MyVar i det lokale funktionsområde ..." $ local: MyVar = "Dette er MyVar i funktionens lokale anvendelsesområde." 'Ændring af $ MyVar i scriptets rækkevidde ... '$ script: MyVar =' MyVar blev indstillet af et script. Nu indstillet af en funktion. 'Ændring af $ MyVar i det globale omfang ...' $ global: MyVar = 'MyVar blev sat i det globale omfang. Nu indstillet af en funktion. "Kontrollerer $ MyVar i hvert omfang ..." "Lokal: $ local: MyVar" "Script: $ script: MyVar" "Global: $ global: MyVar" "}" Få nuværende værdi af $ MyVar. " "MyVar siger $ MyVar" "Ændring af $ MyVar efter script." $ MyVar = 'Jeg blev sat af et script!' "MyVar siger $ MyVar" FunctionScope "Kontrollerer $ MyVar fra scriptomfanget før afslutningen. ' "MyVar siger $ MyVar" "
Som før begynder vi ved at indstille variablen i det globale omfang og slutte med at kontrollere det endelige globale omfangsresultat.
Her kan du se, at FunctionScope var i stand til at ændre variablen i Script-anvendelsesområdet, og hvis ændringerne fortsætter, efter at den er gennemført, fortsætter ændringen til variablen i det globale omfang, selv efter at scriptet er gået ud. Dette kan være særligt nyttigt, hvis du gentagne gange skal ændre variabler i et script , eller inden for det globale anvendelsesområde, ved hjælp af samme kode - du definerer bare en funktion eller et script, der er skrevet for at ændre variablen, hvor og hvordan du har brug for det, og kalder på det, når disse ændringer er nødvendige.
Som nævnt tidligere, anvendelsesnumre kan også bruges i visse kommandoer til at ændre variablen på forskellige niveauer i forhold til lokalområdet. Her er det samme script, der blev anvendt i det andet eksempel ovenfor, men med funktionen ændret til at bruge kommandoerne Variabel og sæt variabel med rækkevidde num bers i stedet for direkte at henvise til variablen med navngivne scopes:
Funktion FunctionScope {"Ændring af $ MyVar i rækkevidde 0, i forhold til FunctionScope ... 'Set-Variable MyVar" Dette er MyVar i funktionens omfang 0. "-Scope 0' Ændrer $ MyVar i rækkevidde 1, i forhold til FunctionScope ... 'Set-Variable MyVar 'MyVar blev ændret i rækkevidde 1, fra en funktion.' -Scope 1 'Ændring af $ MyVar i rækkevidde 2, i forhold til Functionscope ...' Set-Variable MyVar 'MyVar blev ændret i rækkevidde 2, fra en funktion.' -Scope 2 "Kontrollerer $ MyVar i hvert omfang ..." Scope 0: "Variabel MyVar -Scope 0 -ValueOnly" Scope 1: "Variabel MyVar -Scope 1 -ValueOnly" Scope 2: "Variabel MyVar-Scope 2 -ValueOnly "}" Få nuværende værdi af $ MyVar. " "MyVar siger $ MyVar" "Ændring af $ MyVar efter script." $ MyVar = 'Jeg blev sat af et script!' "MyVar siger $ MyVar" FunctionScope "Kontrollerer $ MyVar fra scriptomfanget før afslutningen. ' "MyVar siger $ MyVar" "
Ligesom tidligere kan vi se her, hvordan kommandoer i ét omfang kan ændre objekter i sit overordnede omfang.
Der er stadig meget mere, der kan gøres med scopes end kan passe ind i denne artikel. Scopes påvirker mere end bare variabler, og der er stadig mere at lære om Private scopes og AllScope-variablerne. For mere brugbar information kan du køre følgende kommando fra PowerShell:
Få hjælp om_scopes
Den samme hjælpefil er også tilgængelig på TechNet.
Scope billedkredit: Spadassin på openclipart
Windows 10 giver dig mulighed for at sidelæse universelle apps, ligesom Android gør
Windows 10 markerer et stort skift i filosofien fra Windows 8. I Windows 10 er du fri til at sidelæne din egen universelle apps fra udenfor Windows-butikken - ligesom du kan sideload apps på en Android-telefon eller -tablet. Med Windows 8 kopierede Microsoft Apples iPad og iPhone-model, hvilket tvinger dig til at få dine apps fra Microsofts kuraterede butik.
Sådan tager du bedre billeder med telefonens kamera
De siger, at det bedste kamera er det, du har med dig, og de fleste smartphone-kameraer kan nu nemt erstatte et point-and-shoot. For brugere, der har erfaring med at tage billeder, kan flytningen fra et "rigtigt" kamera til en smartphone være en let, men for brugere uden fotograferingsoplevelse kan det være en reel udfordring at få et anstændigt udseende fra din telefon.