Condividi tramite

about_Scopes

  • Articolo

Descrizione breve

Illustra il concetto di ambito in PowerShell e illustra come impostare e modificare l'ambito degli elementi.

Descrizione lunga

PowerShell protegge l'accesso a variabili, alias, funzioni e unità di PowerShell (PSDrive) limitando la posizione in cui possono essere letti e modificati. PowerShell usa regole di ambito per assicurarsi di non apportare modifiche involontarie agli elementi in altri ambiti.

Regole dell'ambito

Quando si avvia PowerShell, l'host (pwsh.exe) crea uno spazio di esecuzione di PowerShell. I processi host possono avere più spazi di esecuzione. Ogni spazio di esecuzione ha uno stato sessione e contenitori di ambito specifici. Non è possibile accedere allo stato e agli ambiti della sessione tra istanze dello spazio di esecuzione.

Di seguito sono riportate le regole di base dell'ambito:

  • Gli ambiti possono annidare. Un ambito esterno viene definito ambito padre. Tutti gli ambiti annidati sono ambiti figlio di tale elemento padre.
  • Un elemento è visibile nell'ambito creato e in qualsiasi ambito figlio, a meno che non venga esplicitamente impostato come privato.
  • È possibile dichiarare variabili, alias, funzioni e unità di PowerShell per un ambito esterno all'ambito corrente.
  • Un elemento creato all'interno di un ambito può essere modificato solo nell'ambito in cui è stato creato, a meno che non si specifichi in modo esplicito un ambito diverso.
  • Quando il codice in esecuzione in uno spazio di esecuzione fa riferimento a un elemento, PowerShell cerca nella gerarchia di ambito, a partire dall'ambito corrente e procedendo attraverso ogni ambito padre.
    • Se l'elemento non viene trovato, viene creato un nuovo elemento nell'ambito corrente.
    • Se trova una corrispondenza, il valore dell'elemento viene recuperato dall'ambito in cui è stato trovato.
    • Se si modifica il valore, l'elemento viene copiato nell'ambito corrente in modo che la modifica influisca solo sull'ambito corrente.
  • Se si crea in modo esplicito un elemento che condivide il nome con un elemento in un ambito diverso, l'elemento originale potrebbe essere nascosto dal nuovo elemento, ma non viene sottoposto a override o modificato.

Ambiti padre e figlio

È possibile creare un nuovo ambito figlio chiamando uno script o una funzione. L'ambito chiamante è l'ambito padre. Lo script o la funzione denominata è l'ambito figlio. Le funzioni o gli script chiamati possono chiamare altre funzioni, creando una gerarchia di ambiti figlio il cui ambito radice è l'ambito globale.

Nota

Le funzioni di un modulo non vengono eseguite in un ambito figlio dell'ambito chiamante. I moduli hanno il proprio stato di sessione collegato all'ambito in cui è stato importato il modulo. Tutto il codice del modulo viene eseguito in una gerarchia specifica del modulo di ambiti con il proprio ambito radice. Per altre informazioni, vedere la sezione Moduli di questo articolo.

Quando viene creato un ambito figlio, include tutti gli alias e le variabili con l'opzione AllScope e alcune variabili automatiche. Questa opzione è illustrata più avanti in questo articolo.

A meno che gli elementi non vengano esplicitamente resi privati, gli elementi nell'ambito padre sono disponibili per l'ambito figlio. Gli elementi creati o modificati in un ambito figlio non influiscono sull'ambito padre, a meno che non si specifichi in modo esplicito l'ambito quando si creano gli elementi.

Per trovare gli elementi in un particolare ambito, usare il parametro Scope di Get-Variable o Get-Alias.

Ad esempio, per ottenere tutte le variabili nell'ambito locale, digitare:

Get-Variable -Scope local

Per ottenere tutte le variabili nell'ambito globale, digitare:

Get-Variable -Scope global

Quando viene eseguito un riferimento a una variabile, a un alias o a una funzione, PowerShell cerca l'ambito corrente. Se l'elemento non viene trovato, viene eseguita la ricerca nell'ambito padre. Questa ricerca viene ripetuta fino all'ambito globale. Se una variabile è privata in un ambito padre, la ricerca continua attraverso la catena di ambiti. L'esempio 4 mostra l'effetto di una variabile privata in una ricerca nell'ambito.

Nomi degli ambiti di PowerShell

PowerShell definisce i nomi per alcuni ambiti per consentire un accesso più semplice a tale ambito. PowerShell definisce gli ambiti denominati seguenti:

  • Globale: ambito attivo all'avvio di PowerShell o alla creazione di una nuova sessione o di uno spazio di esecuzione. Le variabili e le funzioni presenti all'avvio di PowerShell, ad esempio variabili automatiche e variabili di preferenza, vengono create nell'ambito globale. Anche le variabili, gli alias e le funzioni nei profili di PowerShell vengono create nell'ambito globale. L'ambito globale è l'ambito padre radice in uno spazio di esecuzione.
  • Locale: ambito corrente. L'ambito locale può essere l'ambito globale o qualsiasi altro ambito.
  • Script: ambito creato durante l'esecuzione di un file di script. I comandi nello script vengono eseguiti nell'ambito dello script. Per i comandi in uno script, l'ambito dello script è l'ambito locale.

Per i cmdlet che supportano gli ambiti, gli ambiti possono essere indicati da un numero che descrive la posizione relativa di un ambito a un altro. L'ambito 0 indica l'ambito corrente (locale), l'ambito 1 è l'elemento padre dell'ambito corrente, l'ambito 2 è il padre dell'ambito corrente. Questo modello continua fino a raggiungere l'ambito radice.

Modificatori di ambito

Una variabile, un alias o un nome di funzione può includere uno dei modificatori di ambito facoltativi seguenti:

  • global: - Specifica che il nome esiste nell'ambito globale .

  • local: - Specifica che il nome esiste nell'ambito Locale . L'ambito corrente è sempre l'ambito Locale .

  • private: - Specifica che il nome è Privato e visibile solo all'ambito corrente.

    Nota

    private: non è un ambito. È un'opzione che modifica l'accessibilità di un elemento all'esterno dell'ambito in cui è definita.

  • script: - Specifica che il nome esiste nell'ambito dello script . L'ambito dello script è l'ambito del file di script predecessore più vicino o Globale se non è presente alcun file di script predecessore più vicino.

  • using: - Usato per accedere alle variabili definite in un altro ambito durante l'esecuzione in sessioni remote, processi in background o processi thread.

  • workflow: - Specifica che il nome esiste all'interno di un flusso di lavoro. Nota: i flussi di lavoro non sono supportati in PowerShell v6 e versioni successive.

  • <variable-namespace> - Modificatore creato da un provider POWERShell PSDrive . Ad esempio:

    Spazio dei nomi Descrizione
    Alias: Alias definiti nell'ambito corrente
    Env: Variabili di ambiente definite nell'ambito corrente
    Function: Funzioni definite nell'ambito corrente
    Variable: Variabili definite nell'ambito corrente

L'ambito predefinito per gli script è l'ambito dello script. L'ambito predefinito per funzioni e alias è l'ambito locale, anche se sono definiti in uno script.

Uso dei modificatori di ambito

Per specificare l'ambito di una nuova variabile, un alias o una nuova funzione, usare un modificatore di ambito.

La sintassi per un modificatore di ambito in una variabile è:

$[<scope-modifier>:]<name> = <value>

La sintassi per un modificatore di ambito in una funzione è:

function [<scope-modifier>:]<name> {<function-body>}

Il comando seguente, che non usa un modificatore di ambito, crea una variabile nell'ambito corrente o locale :

$a = "one"

Per creare la stessa variabile nell'ambito globale , usare il modificatore di ambito global: :

$global:a = "one"
Get-Variable a | Format-List *

Si notino i valori delle proprietà Visibility e Options .

Name        : a
Description :
Value       : one
Visibility  : Public
Module      :
ModuleName  :
Options     : None
Attributes  : {}

Confrontarlo con una variabile privata:

$private:pVar = 'Private variable'
Get-Variable pVar | Format-List *

Se si usa il modificatore di private ambito, la proprietà Options viene impostata su Private.

Name        : pVar
Description :
Value       : Private variable
Visibility  : Public
Module      :
ModuleName  :
Options     : Private
Attributes  : {}

Per creare la stessa variabile nell'ambito dello script , usare il modificatore di script: ambito:

$script:a = "one"

È anche possibile usare un modificatore di ambito con funzioni. La definizione di funzione seguente crea una funzione nell'ambito globale :

function global:Hello {
  Write-Host "Hello, World"
}

È anche possibile usare i modificatori di ambito per fare riferimento a una variabile in un ambito diverso. Il comando seguente fa riferimento alla $test variabile, prima nell'ambito locale e quindi nell'ambito globale:

$test
$global:test

Modificatore dell'ambito using:

Using è un modificatore di ambito speciale che identifica una variabile locale in un comando remoto. Senza un modificatore, PowerShell prevede che le variabili nei comandi remoti vengano definite nella sessione remota.

Il using modificatore di ambito viene introdotto in PowerShell 3.0.

Per qualsiasi script o comando che viene eseguito all'esterno della sessione, è necessario il using modificatore di ambito per incorporare i valori delle variabili dall'ambito della sessione chiamante, in modo che il codice fuori sessione possa accedervi. Il using modificatore di ambito è supportato nei contesti seguenti:

  • Comandi eseguiti in remoto, iniziati con Invoke-Command l'uso dei parametri ComputerName, HostName, SSHConnection o Session (sessione remota)
  • Processi in background, avviati con Start-Job (sessione out-of-process)
  • Processi thread, avviati tramite Start-ThreadJob o ForEach-Object -Parallel (sessione di thread separata)

A seconda del contesto, i valori delle variabili incorporate sono copie indipendenti dei dati nell'ambito del chiamante o riferimenti a esso. Nelle sessioni remote e out-of-process, sono sempre copie indipendenti.

Per altre informazioni, vedere about_Remote_Variables.

Un $using: riferimento si espande solo al valore di una variabile. Se si desidera modificare il valore di una variabile nell'ambito del chiamante, è necessario avere un riferimento alla variabile stessa. È possibile creare un riferimento a una variabile recuperando l'istanza PSVariable della variabile. Nell'esempio seguente viene illustrato come creare un riferimento e apportare modifiche in un processo di thread.

$Count = 1
$refOfCount = Get-Variable Count

Start-ThreadJob {
    ($using:refOfCount).Value = 2
} | Receive-Job -Wait -AutoRemoveJob

$Count

2

Nota

Non si tratta di un'operazione thread-safe. È possibile causare il danneggiamento dei dati se si tenta di modificare il valore da più thread contemporaneamente. È consigliabile usare tipi di dati thread-safe o primitive di sincronizzazione per proteggere i dati condivisi. Per altre informazioni, vedere Raccolte thread-safe.

Serializzazione dei valori delle variabili

I comandi e i processi in background eseguiti in remoto vengono eseguiti out-of-process. Le sessioni out-of-process usano la serializzazione basata su XML e la deserializzazione per rendere disponibili i valori delle variabili attraverso i limiti del processo. Il processo di serializzazione converte gli oggetti in un PSObject che contiene le proprietà degli oggetti originali, ma non i relativi metodi.

Per un set limitato di tipi, la deserializzazione riattiva gli oggetti nel tipo originale. L'oggetto riattivato è una copia dell'istanza dell'oggetto originale. Ha le proprietà e i metodi del tipo. Per i tipi semplici, ad esempio System.Version, la copia è esatta. Per i tipi complessi, la copia è imperfetta. Ad esempio, gli oggetti certificato riattivati non includono la chiave privata.

Le istanze di tutti gli altri tipi sono istanze di PSObject . La proprietà PSTypeNames contiene il nome del tipo originale preceduto da Deserialized, ad esempio Deserialized.System.Data.DataTable

Opzione AllScope

Le variabili e gli alias hanno una proprietà Option che può accettare un valore di AllScope. Gli elementi con la proprietà AllScope diventano parte di tutti gli ambiti figlio creati, anche se non vengono ereditati retroattivamente dagli ambiti padre.

Un elemento con la proprietà AllScope è visibile nell'ambito figlio e fa parte di tale ambito. Le modifiche apportate all'elemento in qualsiasi ambito influiscono su tutti gli ambiti in cui viene definita la variabile.

Gestione dell'ambito

Diversi cmdlet hanno un parametro Scope che consente di ottenere o impostare (creare e modificare) elementi in un determinato ambito. Usare il comando seguente per trovare tutti i cmdlet nella sessione con un parametro Scope :

Get-Help * -Parameter scope

Per trovare le variabili visibili in un determinato ambito, usare il Scope parametro di Get-Variable. Le variabili visibili includono variabili globali, variabili nell'ambito padre e variabili nell'ambito corrente.

Ad esempio, il comando seguente ottiene le variabili visibili nell'ambito locale:

Get-Variable -Scope local

Per creare una variabile in un determinato ambito, usare un modificatore di ambito o il parametro Scope di Set-Variable. Il comando seguente crea una variabile nell'ambito globale:

New-Variable -Scope global -Name a -Value "One"

È anche possibile usare il parametro Scope dei New-Aliascmdlet , Set-Aliaso Get-Alias per specificare l'ambito. Il comando seguente crea un alias nell'ambito globale:

New-Alias -Scope global -Name np -Value Notepad.exe

Per ottenere le funzioni in un determinato ambito, usare il Get-Item cmdlet quando si è nell'ambito. Il Get-Item cmdlet non ha un parametro Scope .

Nota

Per i cmdlet che usano il parametro Scope , è anche possibile fare riferimento agli ambiti in base al numero. Il numero descrive la posizione relativa di un ambito a un altro. L'ambito 0 rappresenta l'ambito corrente, o locale. L'ambito 1 indica l'ambito padre immediato. L'ambito 2 indica l'elemento padre dell'ambito padre e così via. Gli ambiti numerati sono utili se sono stati creati molti ambiti ricorsivi.

Uso della notazione dot-source con ambito

Gli script e le funzioni seguono le regole dell'ambito. È possibile crearli in un determinato ambito e influiscono solo su tale ambito, a meno che non si usi un parametro cmdlet o un modificatore di ambito per modificare tale ambito.

Tuttavia, è possibile aggiungere il contenuto di uno script o di una funzione all'ambito corrente usando la notazione dot-source. Quando si esegue uno script o una funzione usando la notazione dot-source, viene eseguito nell'ambito corrente. Tutte le funzioni, gli alias e le variabili nello script o nella funzione vengono aggiunte all'ambito corrente.

Ad esempio, per eseguire lo Sample.ps1 script dalla C:\Scripts directory nell'ambito dello script (impostazione predefinita per gli script), immettere semplicemente il percorso completo del file di script nella riga di comando.

c:\scripts\sample.ps1

Un file script deve avere un'estensione .ps1 di file eseguibile. I file con spazi nel percorso devono essere racchiusi tra virgolette. Se si tenta di eseguire il percorso tra virgolette, PowerShell visualizza il contenuto della stringa tra virgolette anziché eseguire lo script. L'operatore di chiamata (&) consente di eseguire il contenuto della stringa contenente il nome file.

L'uso dell'operatore di chiamata per eseguire una funzione o uno script lo esegue nell'ambito dello script. L'uso dell'operatore di chiamata non è diverso dall'esecuzione dello script in base al nome.

& c:\scripts\sample.ps1

Per altre informazioni sull'operatore di chiamata, vedere about_Operators.

Per eseguire lo Sample.ps1 script nell'ambito locale digitare un punto e uno spazio (. ) prima del percorso dello script:

. c:\scripts\sample.ps1

Tutte le funzioni, gli alias o le variabili definite nello script vengono ora aggiunte all'ambito corrente.

Limitazione senza ambito

PowerShell include alcune opzioni e funzionalità simili all'ambito e possono interagire con gli ambiti. Queste funzionalità possono essere confuse con l'ambito o il comportamento dell'ambito.

Sessioni, moduli e prompt annidati sono ambienti autonomi, non ambiti figlio dell'ambito globale nella sessione.

Sessioni

Una sessione è un ambiente in cui viene eseguito PowerShell. Quando si crea una sessione in un computer remoto, PowerShell stabilisce una connessione permanente al computer remoto. La connessione permanente consente di usare la sessione per più comandi correlati.

Poiché una sessione è un ambiente indipendente, ha un proprio ambito, ma una sessione non è un ambito figlio della sessione in cui è stata creata. La sessione inizia con il proprio ambito globale. Questo ambito è indipendente dall'ambito globale della sessione. È possibile creare ambiti figlio nella sessione. Ad esempio, è possibile eseguire uno script per creare un ambito figlio in una sessione.

moduli

È possibile usare un modulo di PowerShell per condividere e distribuire gli strumenti di PowerShell. Un modulo è un'unità che può contenere cmdlet, script, funzioni, variabili, alias e altri elementi utili. A meno che non venga esportato in modo esplicito (usando Export-ModuleMember o il manifesto del modulo), gli elementi di un modulo non sono accessibili all'esterno del modulo. Pertanto, è possibile aggiungere il modulo alla sessione e usare gli elementi pubblici senza preoccuparsi che gli altri elementi possano eseguire l'override dei cmdlet, degli script, delle funzioni e di altri elementi nella sessione.

Per impostazione predefinita, i moduli vengono caricati nell'ambito a livello radice (globale) dello spazio di esecuzione. L'importazione di un modulo non modifica l'ambito. All'interno della sessione, i moduli hanno un proprio ambito. Si consideri il modulo C:\temp\mod1.psm1seguente:

$a = "Hello"

function foo {
    "`$a = $a"
    "`$global:a = $global:a"
}

A questo punto viene creata una variabile $aglobale, assegnargli un valore e chiamare la funzione foo.

$a = "Goodbye"
foo

Il modulo dichiara la variabile $a nell'ambito del modulo, quindi la funzione restituisce il valore della variabile in entrambi gli ambiti.

$a = Hello
$global:a = Goodbye

I moduli creano contenitori di ambito parallelo collegati all'ambito in cui sono stati importati. Gli elementi esportati dal modulo sono disponibili a partire dal livello di ambito in cui vengono importati. Gli elementi non esportati dal modulo sono disponibili solo all'interno del contenitore dell'ambito del modulo. Le funzioni nel modulo possono accedere agli elementi nell'ambito in cui sono stati importati e gli elementi nel contenitore dell'ambito del modulo.

Se si carica Module2 da Module1, Module2 viene caricato nel contenitore di ambito di Module1. Tutte le esportazioni da Module2 vengono inserite nell'ambito del modulo corrente di Module1. Se si usa Import-Module -Scope local, le esportazioni vengono inserite nell'oggetto ambito corrente anziché nel livello superiore. Se si è in un modulo e si carica un altro modulo usando Import-Module -Scope global (o Import-Module -Global), tale modulo e le relative esportazioni vengono caricati nell'ambito globale anziché nell'ambito locale del modulo. La funzionalità WindowsCompatibility esegue questa operazione per importare i moduli proxy nello stato della sessione globale.

Richieste annidate

Le richieste annidate non hanno un proprio ambito. Quando si immette un prompt annidato, il prompt annidato è un subset dell'ambiente. Tuttavia, si rimane all'interno dell'ambito locale.

Gli script hanno un proprio ambito. Se si esegue il debug di uno script e si raggiunge un punto di interruzione nello script, immettere l'ambito dello script.

Opzione privata

Gli alias e le variabili hanno una proprietà Option che può accettare il valore Private. Gli elementi con l'opzione Private possono essere visualizzati e modificati nell'ambito in cui vengono creati, ma non possono essere visualizzati o modificati all'esterno di tale ambito.

Ad esempio, se si crea una variabile con un'opzione privata nell'ambito globale e quindi si esegue uno script, Get-Variable i comandi nello script non visualizzano la variabile privata. L'uso del modificatore di ambito globale in questa istanza non visualizza la variabile privata.

È possibile usare il parametro Option dei New-Variablecmdlet , Set-Variable, New-Aliase Set-Alias per impostare il valore della proprietà Option su Private.

Visibilità

La proprietà Visibility di una variabile o di un alias determina se è possibile visualizzare l'elemento all'esterno del contenitore in cui è stato creato. Un contenitore può essere un modulo, uno script o uno snap-in. La visibilità è progettata per i contenitori nello stesso modo in cui il Private valore della proprietà Option è progettato per gli ambiti.

La proprietà Visibility accetta i Public valori e Private . Gli elementi con visibilità privata possono essere visualizzati e modificati solo nel contenitore in cui sono stati creati. Se il contenitore viene aggiunto o importato, gli elementi con visibilità privata non possono essere visualizzati o modificati.

Poiché la visibilità è progettata per i contenitori, funziona in modo diverso in un ambito.

  • Se si crea un elemento con visibilità privata nell'ambito globale, non è possibile visualizzare o modificare l'elemento in alcun ambito.
  • Se si tenta di visualizzare o modificare il valore di una variabile con visibilità privata, PowerShell restituisce un messaggio di errore.

È possibile usare i New-Variable cmdlet e Set-Variable per creare una variabile con visibilità privata.

Esempi

Esempio 1: Modificare un valore di variabile solo in uno script

Il comando seguente modifica il valore della $ConfirmPreference variabile in uno script. La modifica non influisce sull'ambito globale.

Prima di tutto, per visualizzare il valore della $ConfirmPreference variabile nell'ambito locale, usare il comando seguente:

PS>  $ConfirmPreference
High

Creare uno script Scope.ps1 contenente i comandi seguenti:

$ConfirmPreference = "Low"
"The value of `$ConfirmPreference is $ConfirmPreference."

Eseguire lo script. Lo script modifica il valore della $ConfirmPreference variabile e quindi ne segnala il valore nell'ambito dello script. L'output dovrebbe essere simile all'output seguente:

The value of $ConfirmPreference is Low.

Testare quindi il valore corrente della $ConfirmPreference variabile nell'ambito corrente.

PS>  $ConfirmPreference
High

Questo esempio mostra che le modifiche apportate al valore di una variabile nell'ambito dello script non influiscono sul valore della variabile nell'ambito padre.

Esempio 2: Visualizzare un valore di variabile in ambiti diversi

È possibile usare i modificatori di ambito per visualizzare il valore di una variabile nell'ambito locale e in un ambito padre.

Prima di tutto, definire una $test variabile nell'ambito globale.

$test = "Global"

Creare quindi uno Sample.ps1 script che definisce la $test variabile. Nello script usare un modificatore di ambito per fare riferimento alle versioni globali o locali della $test variabile.

In Sample.ps1:

$test = "Local"
"The local value of `$test is $test."
"The global value of `$test is $global:test."

Quando si esegue Sample.ps1, l'output dovrebbe essere simile all'output seguente:

The local value of $test is Local.
The global value of $test is Global.

Al termine dello script, nella sessione viene definito solo il valore globale di $test .

PS> $test
Global

Esempio 3: Modificare il valore di una variabile in un ambito padre

A meno che non si protegga un elemento usando l'opzione Private o un altro metodo, è possibile visualizzare e modificare il valore di una variabile in un ambito padre.

Prima di tutto, definire una $test variabile nell'ambito globale.

$test = "Global"

Creare quindi uno script Sample.ps1 che definisce la $test variabile. Nello script usare un modificatore di ambito per fare riferimento alle versioni globali o locali della $test variabile.

In Sample.ps1:

$global:test = "Local"
"The global value of `$test is $global:test."

Al termine dello script, il valore globale di $test viene modificato.

PS> $test
Local

Esempio 4: Creazione di una variabile privata

Una variabile può essere resa privata usando il modificatore di private: ambito o creando la variabile con la proprietà Option impostata su Private. Le variabili private possono essere visualizzate o modificate solo nell'ambito in cui sono state create.

In questo esempio lo ScopeExample.ps1 script crea cinque funzioni. La prima funzione chiama la funzione successiva, che crea un ambito figlio. Una delle funzioni ha una variabile privata che può essere vista solo nell'ambito in cui è stata creata.

PS> Get-Content ScopeExample.ps1
# Start of ScopeExample.ps1
function funcA {
    "Setting `$funcAVar1 to 'Value set in funcA'"
    $funcAVar1 = "Value set in funcA"
    funcB
}

function funcB {
    "In funcB before set -> '$funcAVar1'"
    $private:funcAVar1 = "Locally overwrite the value - child scopes can't see me!"
    "In funcB after set  -> '$funcAVar1'"
    funcC
}

function funcC {
    "In funcC before set -> '$funcAVar1' - should be the value set in funcA"
    $funcAVar1 = "Value set in funcC - Child scopes can see this change."
    "In funcC after set  -> '$funcAVar1'"
    funcD
}

function funcD {
    "In funcD before set -> '$funcAVar1' - should be the value from funcC."
    $funcAVar1 = "Value set in funcD"
    "In funcD after set  -> '$funcAVar1'"
    '-------------------'
    ShowScopes
}

function ShowScopes {
    $funcAVar1 = "Value set in ShowScopes"
    "Scope [0] (local)  `$funcAVar1 = '$(Get-Variable funcAVar1 -Scope 0 -ValueOnly)'"
    "Scope [1] (parent) `$funcAVar1 = '$(Get-Variable funcAVar1 -Scope 1 -ValueOnly)'"
    "Scope [2] (parent) `$funcAVar1 = '$(Get-Variable funcAVar1 -Scope 2 -ValueOnly)'"
    "Scope [3] (parent) `$funcAVar1 = '$(Get-Variable funcAVar1 -Scope 3 -ValueOnly)'"
    "Scope [4] (parent) `$funcAVar1 = '$(Get-Variable funcAVar1 -Scope 4 -ValueOnly)'"
}
funcA
# End of ScopeExample.ps1
PS> .\ScopeExample.ps1

L'output mostra il valore della variabile in ogni ambito. È possibile notare che la variabile privata è visibile solo in funcB, l'ambito in cui è stato creato.

Setting $funcAVar1 to 'Value set in funcA'
In funcB before set -> 'Value set in funcA'
In funcB after set  -> 'Locally overwrite the value - child scopes can't see me!'
In funcC before set -> 'Value set in funcA' - should be the value set in funcA
In funcC after set  -> 'Value set in funcC - Child scopes can see this change.'
In funcD before set -> 'Value set in funcC - Child scopes can see this change.' - should be the value from funcC.
In funcD after set  -> 'Value set in funcD'
-------------------
Scope [0] (local)  $funcAVar1 = 'Value set in ShowScopes'
Scope [1] (parent) $funcAVar1 = 'Value set in funcD'
Scope [2] (parent) $funcAVar1 = 'Value set in funcC - Child scopes can see this change.'
Scope [3] (parent) $funcAVar1 = 'Locally overwrite the value - child scopes can't see me!'
Scope [4] (parent) $funcAVar1 = 'Value set in funcA'

Come illustrato dall'output di ShowScopes, è possibile accedere alle variabili da altri ambiti usando Get-Variable e specificando un numero di ambito.

Esempio 5: Uso di una variabile locale in un comando remoto

Per le variabili in un comando remoto creato nella sessione locale, usare il modificatore di using ambito. PowerShell presuppone che le variabili nei comandi remoti siano state create nella sessione remota.

La sintassi è:

$using:<VariableName>

Ad esempio, i comandi seguenti creano una $Cred variabile nella sessione locale e quindi usano la $Cred variabile in un comando remoto:

$Cred = Get-Credential
Invoke-Command $s {Remove-Item .\Test*.ps1 -Credential $using:Cred}

Il using modificatore di ambito è stato introdotto in PowerShell 3.0.

Vedi anche