När ett byggskript behöver en API-nyckel eller en särskild miljöinställning kan du sätta variabeln direkt i PowerShell, men den vanliga metoden gäller bara den aktuella sessionen. Ska värdet finnas kvar efter att terminalen stängts beror kommandot i stället på operativsystemet och på om variabeln ska gälla för dig eller för hela datorn.
Välj omfattning innan du sätter variabeln
- Aktuell session: `$env:APP_ENV = 'Development'` gäller i PowerShell-fönstret och dess underprocesser.
- Beständig variabel i Windows: använd `[Environment]::SetEnvironmentVariable()` med omfattningen `User` eller `Machine`.
- PATH: lägg till en sökväg, skriv inte över hela värdet av misstag.
- setx: ändrar inte den öppna sessionen och kan kapa värden som är längre än 1 024 tecken.
En tilldelning med $env: räcker för den öppna sessionen
För ett lokalt test är den korta formen oftast det smidigaste valet. Skriv exempelvis $env:APP_ENV = 'Development'; variabeln kan därefter läsas med $env:APP_ENV och är tillgänglig för program som startas från samma PowerShell-process.
Ändringen försvinner när processen avslutas. Det är praktiskt när du vill köra ett enstaka byggsteg med en testinställning utan att lämna kvar den i framtida terminaler. Processens barn ärver värdet, men en redan öppnad separat terminal får det inte automatiskt.
$env:APP_ENV = 'Development'
$env:APP_ENV
Remove-Item Env:APP_ENVJag tycker att den här tilldelningen är det bästa förstavalet för felsökning och tillfälliga skript, eftersom den håller ändringen nära kommandot som behöver den. Behöver värdet överleva omstarten av terminalen är nästa fråga vilken beständig omfattning som passar.
User passar ett konto, Machine påverkar hela datorn
En beständig variabel i Windows kan sparas för användarkontot eller på datornivå. Använd `User` för ett personligt utvecklingsverktyg; välj `Machine` endast när värdet ska vara gemensamt och du har behörighet att ändra systeminställningarna.
[Environment]::SetEnvironmentVariable('APP_ENV', 'Production', 'User')
# För alla användare, kör PowerShell med lämplig behörighet
[Environment]::SetEnvironmentVariable('APP_ENV', 'Production', 'Machine')En sådan ändring uppdaterar inte automatiskt miljön i den PowerShell-session som redan körs. Starta en ny terminal för att läsa in det beständiga värdet. Enligt Microsofts dokumentation kan en användar- eller maskinvariabel tas bort genom att sätta värdet till en tom sträng:
[Environment]::SetEnvironmentVariable('APP_ENV', '', 'User')Det finns alltså tre vanliga lägen: Process för nuvarande session, User för ett konto och Machine för datorn. Microsoft Learn om miljövariabler i PowerShell beskriver skillnaderna; på Linux och macOS behöver beständiga värden i regel placeras i operativsystemets eller skalets initieringsfiler i stället.
PATH kräver försiktighet och rätt avgränsare
Att ändra `PATH` är ett typiskt ställe där ett fungerande värde kan råka ersättas av ett ofullständigt. För en tillfällig ändring i Windows-sessionen kan du lägga till en katalog så här:
$env:PATH += ';C:\Tools\MyApp\bin'På Windows skiljs sökvägar i `PATH` åt med semikolon. På Linux och macOS används kolon, så ett exempel för en aktuell PowerShell-session där är $env:PATH += ':/opt/myapp/bin'. Använd inte Windows-avgränsaren på Unix-liknande system.
Ska en sökväg sparas beständigt, hämta först värdet från rätt omfattning och ändra det med omsorg. Ett enkelt sätt att kontrollera vad som faktiskt lagrats är:
[Environment]::GetEnvironmentVariable('PATH', 'User')
[Environment]::GetEnvironmentVariable('PATH', 'Machine')För teamverktyg eller CI-skript är en tillfällig ändring ofta säkrare än en permanent PATH-ändring på arbetsstationen. Om ett kommando fortfarande inte hittas efter en beständig ändring, kontrollera en ny terminal innan du börjar felsöka själva programinstallationen.
setx är beständigt men uppdaterar inte terminalen du använder
Kommandot `setx` kan köras från PowerShell för att spara en variabel för framtida terminalfönster, men det fungerar annorlunda än `$env:`. Microsoft dokumenterar att ändringen inte blir synlig i det aktuella fönstret och att värden längre än 1 024 tecken kapas. Därför bör `setx` undvikas för att skriva om en lång `PATH`-variabel.
setx APP_ENV "Production"
# Maskinomfattning kräver administratörsbehörighet
setx APP_ENV "Production" /mDet vanliga missförståndet är att ett lyckat `setx`-kommando också ändrar miljön i den terminal där det kördes. Det gör det inte: öppna en ny session och läs där värdet med $env:APP_ENV. Microsofts dokumentation för setx varnar dessutom för kapning och för att referenser i befintliga värden kan expanderas.
| Situation | Trolig orsak | Gör så här |
|---|---|---|
| Variabeln syns inte efter att PowerShell stängts | Den sattes med `$env:` och gällde bara processen | Spara den med `SetEnvironmentVariable()` i rätt omfattning på Windows |
| Variabeln syns inte i samma terminal efter `setx` | `setx` ändrar beständigt värde för framtida sessioner | Öppna ett nytt PowerShell-fönster och kontrollera värdet där |
| PATH verkar avklippt eller saknar poster | `setx` kan kapa värden över 1 024 tecken | Återställ från en säker kopia och ändra PATH med en metod som bevarar hela värdet |
| En annan användare behöver variabeln | Värdet sparades bara i `User`-omfattningen | Använd `Machine` på Windows med rätt behörighet |
Välj det minsta omfånget som löser uppgiften
För ett test eller en enskild körning använder du $env:NAME = 'value'. För ett värde som ska finnas kvar för ditt konto i Windows väljer du `User`; `Machine` hör hemma där flera konton behöver samma inställning och administratörsbehörighet finns.
För `PATH` och andra långa värden är det klokt att undvika `setx` och kontrollera resultatet i en ny session. Då slipper du förväxla en beständig inställning med processens redan inlästa miljö, vilket ofta är hela förklaringen när kommandot verkar ha fungerat men värdet ändå inte syns.