Windows PowerShell: Scrittura di cmdlet in script

Don Jones

Una delle nuove funzionalità di Windows PowerShell v2 interessante è la capacità di scrivere funzioni notevolmente migliorate. Queste funzioni, scritte interamente in script, hanno le stesse funzionalità di un cmdlet “ reale ” scritte in C# o Visual Basic e compilate in Visual Studio. Queste funzioni avanzate di (they were originally called “script cmdlets” early in the v2 development cycle) Guida è scrivere funzioni più flessibile è quindi possibile utilizzare perfettamente a fianco dei cmdlet regolari.

È tutto in binding

La reale differenza tra una funzione semplice e un cmdlet completo è che i cmdlet supportano le associazioni di parametri potenti. È possibile utilizzare parametri posizionali, denominati parametri, i parametri obbligatori e anche controlli di convalida base parametro — tutto descrivendo semplicemente il parametro alla shell. Ecco un esempio:

Eseguire il rollback dei moduli

Come è questa guida si distribuiscono gli script più facilmente? Il secondo tipo di modulo, un modulo di script è la risposta. È sufficiente un normale script di Windows PowerShell, con estensione .psm1 anziché l'estensione ps1 normale. Inserimento mymodule.psm1 nella cartella \modules consente di eseguire Modulo Importa MyModule e verrà eseguito lo script.

In genere, un modulo di script consiste in interamente delle funzioni. Vale a dire quando il modulo viene importato, nulla effettivamente eseguito, le funzioni all'interno del modulo di script vengono caricate nella shell e diventano disponibili all'interno della shell. Si supponga che un modulo di script simile al seguente:

function Get-Inventory {
    [CmdletBinding()]
    param (
        [parameter(Mandatory=$true,ValueFromPipeline=$true)]
        [string[]]$computername,
        
        [parameter(Mandatory=$false)]
        [alias("PF")]
        [switch]$pingfirst,
        
        [parameter(Mandatory=$true,Position=0)]
        [AllowEmptyString()]
        [string]$class
        
    )
    PROCESS {
    }
}

In questa istruzione, ho dichiarato tre parametri:

  • nomecomputer è una stringa o una matrice di stringhe. È obbligatorio e accetta input di stringa della pipeline, ovvero se pipe in una serie di stringhe, essi verranno automaticamente eliminate nella variabile $ nomecomputer.
  • pingfirst non è obbligatoria, ma se si utilizza, è consigliabile utilizzare alias - PF. Digitando un po' verrà salvata. Si tratta di un parametro di opzione, ovvero che non accetta un valore. È sia attivata o disattivata.
  • classe inoltre è obbligatorio, ma Don ’t nemmeno necessario digitare-nome classe del parametro. Solo assegnargli il valore appropriato come il valore della prima posizione quando si esegue la funzione. Anche se questo campo è obbligatorio, accetta una stringa vuota.

Esistono molti altri attributi e numerosi esempi, nella Guida in linea. Eseguire Guida about_Functions_Advanced_Parameters per visualizzarli tutti.

L'accesso ai parametri comuni

La shell definisce numerosi parametri comuni condivisi da tutti i cmdlet. Uno di essi è - verbose, deve indicare un cmdlet per l'output di informazioni rispetto al solito le operazioni eseguite. La seguente definizione di funzione, tuttavia, verrà generato un errore:

function Test-Something {
    [CmdletBinding()]
    param (
        [switch]$verbose
    )
    PROCESS {
    }
}

Che è Impossibile re-define uno dei parametri comuni come - verbose. Come è possibile stabilire se la funzione è stata eseguita con - verbose o non? Beh, pare essere inutile. Windows PowerShell tiene traccia di esso per l'utente. Write-verbose, è sufficiente chiamare e Windows PowerShell ignorerà le chiamate se - verbose non era utilizzato:

function Test-Something {
    PROCESS {
        Write-Verbose "Starting cmdlet"
    }
}

test-something –verbose

Conferma dell'impatto

Un'altra coppia di parametri comuni è - whatif e - conferma. I cmdlet che rende alcuni tipi di modifica al computer dovrebbe per riconoscere quelli. Esiste la possibilità che il cmdlet di visualizzare ciò che sarebbe normalmente (-whatif), o averlo singolarmente ogni operazione di conferma (- conferma). Insieme, questi parametri vengono chiamati ShouldProcess ed è possibile dichiarare una funzione che supporta questa funzionalità, come illustrato di seguito:

function Delete-Things {
    [CmdletBinding(
        SupportsShouldProcess=$true,
        ConfirmImpact="Medium"
    )]
    PROCESS {
    }
}

Questa dichiarazione consente entrambi - whatif e - conferma come parametri per la funzione. Specifica inoltre che la funzione ha un livello di impatto "Medio" sul sistema operativo. Non esistono rigorose linee guida per "Medio" significa, potrebbe immaginare è qualcosa di meno possibilità di emergenza totale. Il vero trucco è che $ ConfirmPreference variabile della shell automaticamente "Alta". Quando l'impatto di un cmdlet è inferiore a $ ConfirmPreference, quindi il cmdlet verrà eseguito senza conferma se - whatif o - conferma specificati.

Se l'impatto del cmdlet è uguale o superiore a $ ConfirmPreference, quindi ogni volta che si esegue il cmdlet, essa funzionerà come se fosse specificato - conferma, anche se si è dimenticato di farlo. Di conseguenza, la funzione sta per eseguire un'operazione molto pericolosa specificare un ConfirmImpact = "Alta" in modo che il cmdlet verrà sempre richiedere conferma. Le opzioni disponibili sono "None" e "Low".

Nessuna Guida incorporata della shell effettivamente illustra come chiesta conferma, e non è automatica. La Guida si riferisce la Guida MSDN in linea, che è destinato agli sviluppatori Microsoft .NET Framework e non riferimento in qualsiasi linguaggio di script della shell. Pertanto verrà mostrato di seguito:

function Delete-Things {
    [CmdletBinding(
        SupportsShouldProcess=$true,
        ConfirmImpact="High"
    )]
    Param ($param1)
    PROCESS {
        if ($pscmdlet.ShouldProcess($param1)) {
            Write "Deleting..."
        }
    }
}

Delete-Things "organizationalunit"

pscmdlet $ è una variabile incorporata, è possibile utilizzare nel blocco di script PROCESS alla funzionalità di accesso a livello di cmdlet, incluso il metodo ShouldProcess. Passare in una descrizione di ciò che si sta per modificare e della shell verrà occuparsi di visualizzare la conferma effettiva o “ se ” del messaggio.

Se ShouldProcess restituisce $ true, quindi consente di continuare. If it returns $False, then you should not do whatever it is you were about to do. Once you know about the $pscmdlet variable, making sense of those MSDN developer docs is easier. Descrivono accuratamente i diversi modi in cui è consigliabile utilizzare ShouldProcess e i compagni — ad esempio ShouldContinue.

Aiuto! Aiuto! Aiuto!

Non dimenticare che funzioni, anche quelle avanzate, può contenere la propria Guida incorporata nei commenti formattati in modo speciale, come descritto nel mio colonna marzo 2010 . In genere, è possibile elencare la Guida con commento prima, quindi l'istruzione CmdletBinding, i parametri e quindi {} BEGIN, PROCESS {} ed END scriptblocks {}. Sempre consigliabile includere informazioni all'interno delle funzioni è, mai sapere chi può beneficiare.

Se si scrive pipeline funzioni prima (anche denominato “ filtro funzioni ”), quindi si conosce già tutto il resto che è necessario conoscere per scrivere un cmdlet di script “. ” Il blocco di script PROCESS {} è dove inserire codice e verrà eseguita una volta per ogni oggetto reindirizzato nel cmdlet. Tutte le altre informazioni su queste avanzate funzioni è inoltre come controparti piuttosto semplice.

Windows PowerShell v2 è ora disponibile

Although it shipped pre-installed with Windows Server 2008 R2 and Windows 7, Windows PowerShell v2—and its companion Management Framework components—is now available for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Visit support.microsoft.com/kb/968929to get the download link for whatever OS you’re using. Devono essere compatibile con gli script v1 e tutte le colonne future presupporrà che si sta utilizzando 2.0.

Gruppi di un intervallo di destinatari

Assume il team di Windows PowerShell estremamente specifiche e solo che Windows PowerShell utili per una vasta gamma di destinatari con vari livelli di competenza. Un esempio di qualcosa di utile solo un Avanzate pubblico sono certamente funzioni avanzate.

Se si desidera iniziare con la shell e per ricordarsi di eseguire Guida , quindi funzioni avanzate sono probabilmente ancora disattivato in futuro. È possibile utilizzare la shell correttamente senza mai scrivere una funzione avanzata. Una volta che si avvia acquisizione più avanzate e iniziare a scrivere componenti riutilizzabili, troverete che funzioni avanzate sono un ottimo modo per farlo.

Di registrare il blog qui è un ottimo esempio: Inizia con un semplice comando che esegue un'attività importante, ovvero un elemento qualsiasi amministratore può scrivere. Quindi l'autore espande gradualmente in una funzione, una funzione di filtraggio e infine una funzione avanzata delle funzionalità del suo comando che mostra come la shell possibile scalare come esigenze e aumentare le competenze.

Don Jones * is a founder of Concentrated Technology, and answers questions about Windows PowerShell and other technologies at * ConcentratedTech.com. He’s also an author for Nexus.Realtimepublishers.com, which makes many of his books available as free electronic editions.

Contenuto correlato

·      Windows PowerShell: PowerShell e Active Directory

·      Windows PowerShell: Filtrare Left, Right formato

·      Windows PowerShell: Stay inserite