Condividi tramite


Windows PowerShell. Definizione di parametri

Ci sono modi semplici e complessi per definire i parametri di Windows PowerShell, e in entrambe le direzioni hanno i loro vantaggi.

Don Jones

Potrai spesso scrivere uno script o una funzione che deve accettare una sorta di input. Questo potrebbe essere un nome di computer, un percorso di file o qualcosa di simile. Si può dire Windows PowerShell aspettarsi questi parametri, raccoglierli dalla riga di comando, e mettere i valori in variabili all'interno di script o funzione. Che consente di gestire input semplice ed efficiente.

Devi solo sapere come dichiarare i parametri. Il mezzo più semplice di farlo è così il blocco param:

Param( [string]$computerName, [string]$filePath )

Non è necessario che si scompongono in righe separate, come ho fatto. È legale eseguire tutti insieme su un'unica riga. Io preferisco una scomposizione per facilitare la lettura, però. Quando viene utilizzato come le prime righe di codice in un file di script o all'interno di una funzione, Windows PowerShell legge questo e saranno i nomi di parametro anche scheda completa quando qualcuno viene eseguito lo script o la funzione. Sono stato attento a utilizzare i nomi di parametro: They're ComputerName e qui – FilePath. Queste sono simili a quelli di altri cmdlet di Windows PowerShell utilizzare per questo genere di informazioni. In questo modo, i miei parametri sono coerenti con ciò che è già in shell.

Se ho messo questo in uno script denominato Get-Something.ps1, vuoi utilizzare i parametri come questo:

./Get-Something –computerName SERVER1 –filePath C:\Whatever

Potrei anche troncati i nomi di parametro. Questo mi permette di digitare i caratteri meno e funzionano ancora:

./Get-Something –comp SERVER1 –file C:\Whatever

Anche potuto omettere i nomi interamente. Windows PowerShell automaticamente e posizionalmente accetta valori. Qui è necessario fare attenzione a fornire valori nello stesso ordine in cui i parametri sono elencati nel mio file:

./Get-Something SERVER1 C:\Whatever

Ovviamente, utilizzando i nomi di parametro, il comando diventa un po ' più facile per una persona per capire. Quindi ottenere il lusso di mettere i parametri nell'ordine che desideri:

./Get-Something –filePath C:\Whatever –computerName SERVER1

Windows PowerShell fornisce anche un modo più complesso di dichiarare i parametri. Questa più vera e propria sintassi consente di definire parametri come obbligatorio, specificare una posizione (se non fai così, allora il parametro può essere utilizzato solo dal nome) e molto altro ancora. Questa sintassi espansa è anche legale in entrambi gli script e funzioni:

[CmdletBinding()] Param( [Parameter(Mandatory=$True,Position=1)] [string]$computerName, [Parameter(Mandatory=$True)] [string]$filePath )

Ancora una volta, è possibile eseguire tutto ciò che insieme su una sola riga, ma abbattendo lo rende un po ' più facile da leggere. Ho dato entrambi i miei parametri un [parameter] decoratore ed entrambi definiti come obbligatori.

Se qualcuno tenta di eseguire il mio script e dimentica uno o entrambi questi parametri, la shell richiederà loro automaticamente. Non non c'è nessun lavoro aggiuntivo da parte mia necessari per realizzare questo obiettivo. Ho anche definito ComputerName come essendo in prima posizione, ma deve essere fornito dal nome – FilePath.

Ci sono alcuni altri vantaggi nell'utilizzo della direttiva [CmdletBinding]. Per uno, esso assicura il mio script o funzione avrà tutti i Windows PowerShell comuni parametri, tra cui – verbose e – debug. Ora, posso utilizzare Write-Verbose e Debug di scrittura all'interno del mio script o la funzione e la loro produzione verrà eliminata automaticamente.

Eseguire lo script o la funzione con – verbose o – debug e Write-Verbose o Write-Debug (rispettivamente) sono magicamente attivato. Che è un ottimo modo per produrre informazioni di avanzamento passo-passo (Write-Verbose) o aggiungere punti di interruzione debug (Write-Debug) negli script.

Come stai attualmente scritto entrambi i parametri accetterà un solo valore. Dichiarandoli come [string []] sarebbe far loro accettare un'intera collezione di valori. Sarebbe quindi enumerare questo utilizzando un ciclo Foreach, così potrebbe lavorare con un valore in un momento.

Un altro tipo di parametro pulito è [switch]:

Param([switch]$DoSomething)

Ora, posso eseguire il mio script o funzione con nessun parametro –DoSomething e internamente DoSomething variabile $ sarà $False. Se si esegue lo script con il parametro –DoSomething, $DoSomething viene impostato su $True. Non c'è c'è bisogno di passare un valore per il parametro. Windows PowerShell imposta su $True se semplicemente includerla. Questo è il funzionano interruttore parametri, ad esempio il parametro –recurse di Get-ChildItem.

Tenete a mente che ogni parametro costituisce una propria entità, e dal parametro successivo è separato da una virgola. Si noterà che in un esempio precedente:

[CmdletBinding()] Param( [Parameter(Mandatory=$True,Position=1)] [string]$computerName, [Parameter(Mandatory=$True)] [string]$filePath )

Il parametro – ComputerName intero, compreso il decoratore [parameter], appare prima della virgola. La virgola indica che mi sono fatto spiegare il primo parametro e io sono pronto a passare a quello successivo. Tutto associato – FilePath segue il punto e virgola. Se avevo bisogno di un terzo parametro, vorrei mettere un'altra virgola:

[CmdletBinding()] Param( [Parameter(Mandatory=$True,Position=1)] [string]$computerName, [Parameter(Mandatory=$True)] [string]$filePath, [switch]$DoSomething )

Tutto questo è contenuto all'interno del blocco Param(). Si noti che non è necessario utilizzare il decoratore [parameter] su ogni parametro. Utilizzarla solo su quelli dove devi dichiarare qualcosa, come ad esempio il parametro essendo obbligatorio, accettare input da pipeline, essendo in una certa posizione e così via. Eseguire la guida about_functions_advanced_parameters in Windows PowerShell per ulteriori informazioni su altri attributi, che è possibile dichiarare in questo modo.

Scrittura di funzioni e script che accettano input solo tramite parametri è una best practice. Li rende più autonomi, più facile al documento e più coerente con il modo il resto delle opere di shell.

Don Jones

**Don Jones**è un Microsoft MVP Award destinatario e autore di "Imparare Windows PowerShell in un mese di pranzi" (Manning Publications, 2011), un libro progettato per aiutare qualsiasi amministratore diventa efficace con Windows PowerShell. Jones offre anche formazione di Windows PowerShell pubblica e in loco. Contatto con lui attraverso ConcentratedTech.com o bit.ly/AskDon.

Contenuti correlati