Windows PowerShell. Script PowerShell rispetto a flussi di lavoro PowerShell
Ogni mese dell'anno, Don Jones presenterà una puntata in un parte 12-tutorial su Windows PowerShell del flusso di lavoro. Ti invitiamo a leggere la serie nell'ordine, cominciando con il gennaio 2013 colonna.
Don Jones
Flussi di lavoro aspetto un po ' come una funzione Windows PowerShell o script, ma non lo sono. La somiglianza è solo superficiale, e non può essere anche tutto il senso attraverso la pelle.
Bisogna ricordare che Windows PowerShell ha per tradurre i flussi di lavoro in una tecnologia totalmente separata — Windows Workflow Foundation (WF). Ciò significa che si possono solo fare le cose che è possibile duplicare in WF. Il codice verrà eseguito in un tipo completamente diverso di ambiente che ha le proprie regole e restrizioni. In realtà, le differenze tra un flusso di lavoro e uno script "normale" possono essere significative.
Uno spazio di esecuzione contro molti
In un normale script, tutto nello script viene eseguito in un singolo runspace, con una gerarchia di singolo ambito. Un runspace è approssimativamente equivalente a un processo di Windows PowerShell . Se si pensa che una finestra di console Windows PowerShell , che è un singolo spazio di esecuzione. Ciò significa che tutto è lo stesso, coerente e persistente all'interno di tale spazio.
Le variabili, i comandi, azionamenti e quant'altro tutti iniziano un modo. Rimanere lo stesso a meno che non li modifichi. All'interno di tale spazio, tutte le modifiche si fanno "bastone" per la durata di tale processo.
In un flusso di lavoro, ogni attività, ogni comando, blocco di script inline e così via — può avere il proprio spazio. Ciò significa che se si apporta una modifica in uno, potrebbe non essere visibile in tutti gli altri. Impostazione di una variabile in una parte del flusso di lavoro potrebbe non apportare qualsiasi modifica in un'altra parte del flusso di lavoro, a meno che non si prendono misure speciali per garantire, in caso contrario.
Come si è visto nel articolo del mese scorso, se si definisce una variabile a livello di flusso di lavoro, esiste in tutto il flusso di lavoro (il sistema prende misure per assicurarsi che questo è vero). Se un comando all'interno del flusso di lavoro viene creata una variabile, tale variabile non sarà disponibile per il resto del flusso di lavoro.
Questo significa modulo uso è anche diverso. Importazione di un modulo a un certo punto non necessariamente rende i comandi disponibili in un momento successivo. È necessario prendere cura molto di più, perché un singolo flusso di lavoro essenzialmente può estendersi su più ambiti indipendenti.
Differenze sintattiche
Ci sono un certo numero di differenze di sintassi all'interno di un flusso di lavoro, che alcuni dei quali io ho sottolineato nei precedenti articoli di questa serie:
- Non è possibile utilizzare i parametri posizionali. Deve precisare ogni parametro di comando. Se siete abituati a esecuzione Dir C:\Windows, è necessario imparare Get-ChildItem – path C:\Windows invece. È ancora possibile utilizzare pseudonimi (come Dir) o troncati i nomi di parametro (ad esempio –Comput per ComputerName).
- Flussi di lavoro possono avere parametri, ma possono includere solo lettere, numeri, il carattere di sottolineatura e il trattino nei loro nomi. Che è diversa dalle normali regole di script Windows PowerShell .
- Non è possibile importare un modulo nella sessione del flusso di lavoro. Infatti, i comandi non possono davvero cambiare la sessione corrente e avere alcun effetto sui successivi comandi. Se un flusso di lavoro deve utilizzare un modulo, è necessario utilizzare il parametro di attività –PSRequiredModules.
- Per le attività InlineScript e i comandi che dispongono di implementazioni di attività del flusso di lavoro, si ottiene un sacco di parametri del comando extra, tra cui il parametro di –PSRequiredModules citato in precedenza.
- Impossibile eseguire metodi di oggetti in un flusso di lavoro, a meno che farlo all'interno di un blocco di script inline. L'oggetto deve essere prodotta all'interno del blocco di script inline per il metodo di lavorare.
- Non è possibile script dot-source.
- Non è possibile utilizzare l'operatore di chiamata "&".
- Costrutti switch devono includere il parametro –CaseSensitive. L'equivalente del flusso di lavoro del costrutto Switch è nativamente tra maiuscole e minuscole. Istruzioni switch devono utilizzare costanti. È possibile utilizzare gli operatori di confronto, le espressioni regolari, i riferimenti ai file o blocchi di script. Fondamentalmente, cercare di evitare costrutti Switch.
- Break e Continue dichiarazioni non sono ammessi.
- Solo PSDrives aggiunto da fornitori di Windows PowerShell core — file system, Registro di sistema, archivio certificati, ambiente, funzione, variabile e WS-Management — sono validi. Per utilizzare un PSDrive creato da un modulo, eseguire le attività con un parametro –PSRequiredModules e specificare il nome del modulo.
Sì, è un sacco di differenze. Se sei un programmatore di Windows PowerShell attento, si incorrerà contro meno di questi, come ad esempio i parametri di denominazione. Incontrerai ancora differenze che hai dimenticato fino a diventare davvero familiarità con la scrittura di flussi di lavoro.
Bonus
Windows PowerShell Flusso di lavoro non è tutte le differenze di cattive notizie, infatti, ti dà un sacco di funzionalità gratuitamente. Ogni flusso di lavoro guadagna parametri incorporati, tra cui:
- AsJob gestisce il flusso di lavoro come processo in background. Si può dare un nome di processo utilizzando –JobName.
- –PSComputerName gestisce il flusso di lavoro sul computer designato o sul computer, utilizzando Windows PowerShell remoting.
- –PSCredential e una varietà di parametri relativi consentono di specificare le informazioni di autenticazione alternativo.
- –PSPort e altri parametri relativi alla connessione consentono di specificare dettagli connettività alternativo per il componente di comunicazione remota del flusso di lavoro.
Si noti che un certo numero di questi parametri inizia con –PS? Che ha chiamato uno spazio dei nomi. Si dovrebbe evitare la creazione di propri parametri che iniziano anche con –PS. Se una futura versione di Windows PowerShell aggiunge nuovi parametri, probabilmente si inizierà con –PS. Se generalmente evitare tale prefisso è evitare collisioni con i propri nomi di parametro.
Non peggio, non meglio, ma diverso
Il risultato pratico qui è che i flussi di lavoro non sono script Windows PowerShell . Sono differenti. Essi hanno alcune differenze che possono rendere la vita più facile. Alcune altre differenze possono richiedere un po ' più lavoro da voi. Conoscere le differenze possono aiutarti di più rapidamente iniziare a scrivere i flussi di lavoro efficace.
.jpg)
Don Jones è un Windows PowerShell MVP Award destinatario e un redattore di TechNet Magazine*.*Egli è coautore di quattro libri su Windows PowerShell versione 3, compresi quelli gratuiti su Windows PowerShell remoting e creazione di report HTML in Windows PowerShell. Trovarli tutti a PowerShellBooks.com, o porre domande di Jones nei forum di discussione a PowerShell.org.