Windows PowerShell: il ciclo di vita di funzione avanzata

Funzioni avanzate di Windows PowerShell, chiamato i cmdlet di Script, ovvero può essere un po' di confusione, ma Ecco un modo per indirizzare le relative funzioni di pulitura e installazione.

Don Jones

Si è verificato un costante punto di confusione per un numero di studenti in alcune delle mie lezioni Windows PowerShell on-site. Mi auguro che visitarne le pagine in modo più dettagliato qui aiuterà confusione per l'utente anche di rimozione. Le funzioni avanzate del Windows PowerShell, detta informale i cmdlet di script si trova l'argomento. Il modello per questo tipo di funzione ha il seguente aspetto:

Function Do-Something { [CmdletBinding()] param( [Parameter(Mandatory=$True, ValueFromPipeline=$True)] [string[]]$computername ) BEGIN {} PROCESS {} END {} }

Esistono un paio di aspetti poco chiari a questi cmdlet. Ad esempio, in questo progetto è un parametro di input definito - nomecomputer. Ciò può accettare l'input dalla tubazione. Ciò significa che è possibile chiamare questa funzione in due modi diversi. In primo luogo, è possibile stringhe reindirizzate, ad esempio da un file di testo che contiene un nome di computer per riga:

Get-Content names.txt | Do-Something

È possibile anche semplicemente uno o più nomi di computer passato direttamente al parametro, senza utilizzare affatto la pipeline:

Do-Something –computername SERVER1,SERVER2

Nel primo esempio, blocco BEGIN della funzione eseguito per primo. Quindi, il blocco PROCESS viene eseguito una sola volta per ogni nome reindirizzato nel computer. La variabile nomecomputer $ contiene un solo nome del computer alla volta. Infine, dopo che essi sono elaborati tutti, il blocco END viene eseguito una sola volta.

Nel secondo esempio, i blocchi BEGIN ed END non prevedono l'esecuzione. Il blocco PROCESS viene eseguito una sola volta e nomecomputer $ contiene tutti i nomi che è stato passato al parametro.

Questa differenza nel comportamento extreme può rendere difficile l'installazione e le attività di pulitura che vengono eseguiti in entrambi i casi. Può anche provocare confusione sulla gestione con i parametri di nomecomputer $. Nel primo esempio contiene solo un valore alla volta, mentre nel secondo conterrà uno o più valori, a seconda di ciò che è stato specificato per il parametro-ComputerName. È possibile risolvere il problema nomecomputer $ inserendo semplicemente un ciclo ForEach all'interno del blocco del processo:

Function Do-Something { [CmdletBinding()] param( [Parameter(Mandatory=$True, ValueFromPipeline=$True)] [string[]]$computername ) BEGIN {} PROCESS { Foreach ($computer in $computername) { # use $computer here } } END {} }

Questa tecnica garantirà che la variabile computer $ dovrà contenere un solo nome del computer alla volta, perciò è meglio lavorare che piuttosto nomecomputer $.

Il programma di installazione e pulitura è un po' più complicato. Non si desidera eseguire il programma di installazione direttamente nel blocco del processo. Tale blocco è possibile eseguire più volte quando gli oggetti sono pipeline. D'altro canto, non è possibile inserire l'installazione direttamente nel blocco BEGIN. Che non viene eseguito se non viene reindirizzato. Esistono ovviamente per molti aspetti, che è possibile affrontare questi problemi, ma ciò sembra essere il migliore:

Function Do-Something { [CmdletBinding()] param( [Parameter(Mandatory=$True, ValueFromPipeline=$True)] [string[]]$computername ) BEGIN { $setup_done = $false function DoSomethingSetup { set-variable -name setup_done -value $true -scope 1 } DoSomethingSetup } PROCESS { if (-not $setup_done) { DoSomethingSetup } Foreach ($computer in $computername) { # use $computer here } } }

Questo sistema sfrutta il fatto che i blocchi BEGIN, processo ed END condividano un ambito comune, ovvero che condividono le stesse variabili. Mediante l'impostazione di una variabile come flag, avere la certezza che il contenuto della chiave del blocco BEGIN, ovvero la funzione DoSomethingSetup, chiamato una sola volta.

Si noti che "DoSomethingSetup" funzione è necessario utilizzare una tecnica speciale per l'impostazione del flag di $True una volta si aver completato le operazioni di configurazione. Poiché si tratta di una funzione, DoSomethingSetup ha un proprio ambito. Normalmente non può cambiare il valore di una variabile di fuori di tale ambito. È possibile modificare in modo esplicito la variabile necessaria utilizzando il cmdlet Set-variabile.

È un po' più difficile eseguire la stessa presa per le operazioni di pulitura. Nel primo esempio, gli oggetti sono in cui viene reindirizzati in qualcosa, verrà eseguito il blocco finale. Impossibile stoccati le operazioni di pulizia non esiste. Tuttavia, nel secondo esempio in cui niente pipeline finale non verrà mai eseguito. Il blocco PROCESS viene eseguito una sola volta, in modo che esso non sarà necessariamente "sapere" che non è il blocco di fine per iniziare l'esecuzione.

Il blocco PROCESS è non è sufficiente chiamare una funzione all'interno del blocco di fine. Quando gli oggetti sono pipeline, il blocco del processo verrà eseguito più volte, e non si desidera chiamare il blocco finale più volte.

Esistono alcuni modi astuti per risolvere il problema, ma l'approccio più semplice è spesso la migliore: quando è necessario un tipo di attività di pulizia (ad esempio la chiusura di una connessione di database), dimenticare di utilizzare completamente i blocchi BEGIN ed END. Dispone il blocco PROCESS presuppongono che accade solo per eseguire una sola volta, è sufficiente inserire tutti i programma di installazione e pulitura subito il.

Può essere un po' sarebbe uno spreco, ovvero può aprire e chiudere una connessione al database ripetutamente, ad esempio, ma è efficacia. Elimina inoltre la necessità di avere perambulations strani e difficile da seguire all'interno del codice.

Programmazione di queste funzioni per la gestione della pipeline e gli scenari di pipeline non può essere difficoltoso. In alcune colonne imminente sarà condivido alcune delle modalità di che altre persone hanno risolto questo problema, disporre di diverse opzioni da utilizzare nel proprio ambiente.

Denny Cherry

Don Jones è un destinatario di Microsoft MVP Award e autore di serate "informazioni su Windows PowerShell in un mese di con" CO (Manning pubblicazioni., 2010), un libro progettato per aiutare gli amministratori diventano effettive con Windows PowerShell. Jones offre anche la formazione di Windows PowerShell pubblica e on-site. È possibile contattarlo tramite il suo sito Web all'indirizzo ConcentratedTech.com.

Contenuto correlato