Windows PowerShell: Scripts versus fluxos de trabalho do PowerShell
Cada mês do ano, Don Jones apresentará um novo artigo em um tutorial dividido em 12 partes sobre o fluxo de trabalho do Windows PowerShell. Nós encorajamos você a ler a série na ordem, começando com o de janeiro de 2013 coluna.
Don Jones
Fluxos de trabalho aparência muito como um script ou função do Windows PowerShell, mas não eles. Sua semelhança é apenas superficial, e não pode mesmo ser todo o caminho através da pele.
Você tem que lembrar que o Windows PowerShell tem de traduzir a fluxos de trabalho em uma tecnologia completamente separada — Windows Workflow Foundation (WF). Isso significa que você só pode fazer coisas que você pode duplicar em WF. Seu código será executado em um tipo inteiramente diferente do ambiente que tem suas próprias regras e restrições. Na verdade, as diferenças entre um fluxo de trabalho e um script "normal" podem ser significativas.
Um espaço de execução contra muitos
Em um script normal, tudo no script é executado em um espaço de execução único, com uma hierarquia de escopo único. Um espaço de execução é aproximadamente equivalente a um processo do Windows PowerShell. Se você pensar em uma janela de console do Windows PowerShell, que é um espaço de execução único. Isso significa que tudo é a mesma, consistente e persistente dentro desse espaço de execução.
Variáveis, comandos, unidades e tudo mais todos começam de uma maneira. Eles permanecem as mesmas, a menos que você os altere. Dentro desse espaço de execução, quaisquer alterações feitas "vara" para a duração desse processo.
Em um fluxo de trabalho, cada atividade — cada comando, o bloco de script embutido e assim por diante — pode ter seu próprio espaço de execução. Isso significa que se você fizer uma alteração em um, pode não ser visível em todos os outros. Definição de uma variável em uma parte do seu fluxo de trabalho pode não fazer qualquer alteração em outra parte do fluxo de trabalho, a menos que você tomar medidas especiais para garantir caso contrário.
Como você viu na artigo do mês passado, se você definir uma variável no nível superior do fluxo de trabalho, ele existe em todo o fluxo de trabalho (o sistema realiza etapas para certificar-se de que isso é verdade). Se um comando do fluxo de trabalho cria uma variável, essa variável não estará disponível para o resto do fluxo de trabalho.
Isto significa o uso do módulo também é diferente. Importar um módulo em um ponto não necessariamente faz comandos disponíveis em um momento posterior. Você precisa cuidar muito mais, porque um único fluxo de trabalho essencialmente pode abranger vários escopos independentes.
Diferenças sintáticas
Existem algumas diferenças de sintaxe, um fluxo de trabalho, que alguns dos quais já referi em artigos anteriores desta série:
- Você não pode usar parâmetros posicionais. Você deve definir cada parâmetro de comando. Se você está acostumado a correr Dir C:\Windows, você precisará aprender –Path Get-ChildItem C:\Windows em vez disso. Você ainda pode usar aliases (como Dir) ou truncado nomes de parâmetros (como –Comput para – ComputerName).
- Fluxos de trabalho podem ter parâmetros, mas eles só podem incluir letras, números, sublinhado e hífen em seus nomes. Isso é diferente do normais regras de script do Windows PowerShell.
- Você não pode importar um módulo para a sessão de fluxo de trabalho. Na verdade, os comandos não podem realmente alterar a sessão atual e têm qualquer efeito sobre os comandos subseqüentes. Se um fluxo de trabalho precisa usar um módulo, você precisará usar o parâmetro de atividade –PSRequiredModules.
- Para a atividade de InlineScript e comandos que têm implementações de atividade de fluxo de trabalho, você recebe um monte de parâmetros de comando extra, incluindo o parâmetro de –PSRequiredModules mencionado anteriormente.
- Você não pode executar métodos de objetos em um fluxo de trabalho, a menos que você fazê-lo dentro de um bloco de script embutido. O objeto deve ser produzido dentro do bloco de script embutido para que o método funcione.
- Você não pode os scripts de ponto-fonte.
- Você não pode usar o operador "&" de invocação.
- Construções de interruptor devem incluir o parâmetro de –CaseSensitive. O fluxo de trabalho equivalente a construção Switch é nativamente diferencia maiúsculas de minúsculas. Instruções switch devem usar constantes. Você não pode usar operadores de comparação, expressões regulares, referências de arquivo ou blocos de script. Basicamente, tente evitar construções Switch.
- Break e Continue instruções não são permitidas.
- Só PSDrives adicionado por provedores de núcleo do Windows PowerShell — arquivo de sistema, registro, armazenamento de certificados, ambiente, função, variável e WS-Management — são válidos. Para usar um PSDrive criado por um módulo, executar a atividade com o –PSRequiredModules parâmetro e especifique o nome do módulo.
Sim, isso é um monte de diferenças. Se você é um programador cuidadoso do Windows PowerShell, você vai correr contra a menos que estes, como a nomeação de seus parâmetros. Você ainda vai encontrar diferenças que você esqueceu até que você realmente familiarizar-se com a escrita de fluxos de trabalho.
Bônus
Fluxo de trabalho do Windows PowerShell não é todas as diferenças de más notícias — na verdade, dá-lhe uma tonelada de funcionalidade gratuitamente. Cada fluxo de trabalho ganha parâmetros internos, incluindo:
- – AsJob executa o fluxo de trabalho como um trabalho em segundo plano. Você pode dar um nome de trabalho usando o –JobName.
- –PSComputerName executa o fluxo de trabalho no computador designado ou computadores, usando comunicação remota do Windows PowerShell.
- –PSCredential e uma variedade de parâmetros relacionados permitem que você especifique detalhes de autenticação alternativo.
- –PSPort e outros parâmetros relacionados à conexão permitem especificar detalhes de conectividade alternativo para o componente de comunicação remota do fluxo de trabalho.
Observe um número destes parâmetros começam com –PS? Isso é chamado um namespace. Você deve evitar a criação de seus próprios parâmetros que também começam com –PS. Se uma versão futura do Windows PowerShell adiciona novos parâmetros, eles provavelmente vai começar com –PS. Se você geralmente evita que você vai evitar colisões com seus próprios nomes de parâmetro.
Não pior, não melhor, mas diferente
O resultado prático aqui é que os fluxos de trabalho não são scripts do Windows PowerShell. Eles são diferentes. Eles têm algumas diferenças que podem facilitar a sua vida. Algumas outras diferenças podem exigir um trabalho um pouco mais de você. Conhecer as diferenças pode ajudá-lo mais rapidamente começar a escrever os fluxos de trabalho eficazes.
.jpg)
Don Jones é um receptor do prêmio de MVP do Windows PowerShell e editor do TechNet Magazine*.*Ele é co-autor de quatro livros sobre o Windows PowerShell versão 3, incluindo os gratuitos sobre o Windows PowerShell remoting e criação de relatórios HTML no Windows PowerShell. Encontrá-los todos no PowerShellBooks.com, ou fazer perguntas de Jones nos fóruns de discussão em PowerShell.org.