Windows PowerShell: Compartilhamento de seus scripts - agora mais fácil
Don Jones
Uma limitação do Windows PowerShell v1 é que ele não faz muita coisa para tornar mais fácil compartilhamento de script. Com certeza, você pode facilmente copiar um arquivo de script. ps1 para outro computador, ou até mesmo zip ele e enviá-la por email para um colega, mas faça isso com o VBScript há mais de uma década. Se o script incluído funções reutilizáveis, no entanto, quem recebeu de você teria que saber como a fonte de ponto, ou deve terminar precisar para modificá-lo para executar essas funções.
Enfim, era uma situação aceitável — mesmo se não fosse ideal. A situação tornou-se menos aceitável para scripts que foram acompanhadas de modos de exibição de formato personalizado ou extensões de tipos, porque esses arquivos adicionais a ser carregado manualmente no shell para ser usado pelo script.
Com o Windows PowerShell v2, no entanto, mudamos para uma situação quase ideal, graças à introdução dos módulos.
Self-Contained trechos de qualidades de shell
A módulo é simplesmente uma coleção de arquivos que se relacionam. Há duas categorias amplas de módulos: Binário e script.
A binário módulo consiste em um ou mais arquivos DLL, que são compilados a partir de um idioma do Microsoft .NET Framework como translation from VPE for Csharp ou Visual Basic. Na dias v1, chamamos essas PSSnapins e realmente escrita no Visual Studio não mudou muito. Snapins, no entanto, solicitado que você escrever um instalador para registrar seu DLL com o shell. Com um módulo, não é necessária nenhuma instalação. Em vez disso, o módulo é acompanhado por um arquivo .psd1 — um manifesto do módulo. O manifesto é simplesmente um XML que indica qual DLL(s) deve ser carregado. O manifesto também pode especificar arquivos de extensões de tipo que o acompanha (.ps1xml) ou exibir os arquivos (. format.ps1xml).
Aqui está como ele funciona: O módulo deve ser instalado em um subdiretório dentro da pasta \modules do Windows PowerShell. Por padrão, isso é c:\windows\system32\windowspowershell\v1.0\modules. Então, um módulo nomeado “ MyModule ” deve ir em c:\windows\system32\windowspowershell\v1.0\modules\mymodule e o arquivo de manifesto seria mymodule.psd1. Quaisquer arquivos relacionados no módulo normalmente devem ser agrupados em mesma pasta, mantendo-tudo independente.
Para carregar o módulo, você simplesmente executar o Módulo de importação MyModule. O shell examina a \modules pasta por padrão (embora você também pode passar um caminho completo para Módulo de importação se seu módulo estiver localizado em outro lugar), verá que um arquivo .psd1 existe, lê-lo e carrega os arquivos referenciados no. Distribuir o módulo é fácil: Zip apenas até todos os arquivos e copie o arquivo .zip para outro computador — nenhuma instalação necessária.
Implementar seus próprios módulos
Como isso ajuda você distribuir seus scripts mais facilmente? O segundo tipo de módulo, um módulo de scripts, é a resposta. Isso é simplesmente um normal do Windows PowerShell script, com uma extensão de nome de arquivo .psm1 em vez da extensão de nome de arquivo. ps1 usual. Colocar mymodule.psm1 para a pasta \modules permite a execução de Módulo de importação MyModule e o script serão executado.
Normalmente, um módulo de script consiste em totalmente de funções. Isto é, quando o módulo é importado, nada realmente executa — as funções do módulo de script são carregadas no shell e ficam disponíveis em todo o shell. Suponha que você tenha um módulo de script semelhante a este:
Function Get-Inventory {
# (some code goes here)
}
Function Test-Connectivity {
# (some code goes here)
}
Function Write-Inventory {
# (some code goes here)
}
Importar este módulo fará com que o Get-inventário, teste de conectividade and Inventário de gravação funções disponíveis em todo o shell, assim como cmdlets (na verdade, no próximo mês, mostrarei a você como escrever uma função que comporta-se quase exatamente como um cmdlet “ real ”). Suas funções podem até mesmo incluir ajuda baseados em comentário (que demonstrei no minha última coluna), para que alguém poderia importar o módulo e executar o Ajudar a obter inventário para ver instruções sobre como usar essa função.
Às vezes você quer um Little Privacy
Às vezes, você pode ter um módulo de script complexo que inclui funções deve ser usada apenas por outras funções, em vez de um usuário. Por exemplo, talvez pretendo Teste de conectividade and Inventário de gravação ser “ particulares ” no módulo. Isso significa que deve ser chamados por Get-estoque mas Don espera que possam ser chamados diretamente por um usuário do shell.
Por padrão, Módulo de importação imports tudo no módulo, tornando visíveis ao usuário shell cada função. Você pode substituir esse comportamento, simplesmente especificando uma lista das funções de a intenção de fiquem visíveis; tudo ficará oculta do shell do usuário. Para fazer isso, basta executar Exportação ModuleMember no final do seu módulo de script:
Exportação ModuleMember –function obter inventário
Você também pode exportar cmdlets, variáveis e aliases que o script define, se necessário. Run Ajudar a Export-ModuleMember or see Exportação ModuleMember para obter mais detalhes.
Desvantagens do módulo
Para mim, o bummer somente sobre módulos v2 é que o shell parecia ter padrão apenas um local para eles e esse local está na pasta de sistema do Windows — que não é algo que você deseja entrar o hábito de modificação. Mas, em seguida, eu observou a variável de ambiente PSModulePath e descobriu que o shell também será a aparência em sua pasta de documentos em uma subpasta chamada WindowsPowerShell\Modules, e isso é onde eu agora manter todos os módulos que escrevo.
No futuro, você poderá ver também cmdlets projetado para baixar módulos adicionais de repositórios baseados na Internet, não ao contrário a funcionalidade Pêra usados em sistemas UNIX. Esses cmdlets seria mais probabilidade de fazer o download para a pasta Documents ou em algum outro local não-OS e ter o shell pesquisar a pasta documentos para módulos é um padrão inteligente.
Módulos, módulos, em todos os lugares
Porque Don requerem instalação para serem “ vistos ” pelo shell, módulos estão sendo usados muito mais. Na verdade, quase todas as extensões do Windows PowerShell no Windows Server 2008 R2 é empacotada como um módulo — a única exceção sendo PSSnapin para automatizar o backup do Windows Server (executar o Get-PSSnapin –registered para ver se ele está instalado em um servidor). Mais de código de terceiros é fornecido como módulos, também, incluindo os cmdlets que acessar o repositório do código de comunidade em PoshCode.org.
Na verdade, se você for usuário do Windows PowerShell hardcore interessado em escrever seus próprios cmdlets, mas Don queira se aprofundar em programação do .NET Framework no Visual Studio, a combinação de funções avançadas (novamente, que vai ser coluna do próximo mês) e módulos lhe oferece a capacidade de gravar seu próprio shell “ snapins ” inteiramente no script. Apenas as funções avançadas do pacote — que aparência e funcionar como cmdlets — em um script do módulo e você tiver uma biblioteca de códigos reutilizáveis-distribuir.
Windows PowerShell v2 já geralmente está disponível
Embora fornecido pré-instalado com Windows Server 2008 R2 e Windows 7, o Windows PowerShell v2 — e seus componentes de estrutura de gerenciamento complementares — está disponível para Windows XP, Windows Server 2003, Windows Vista e Windows Server 2008. Apenas visite support.Microsoft.com/kb/968929 para obter o link de download para qualquer sistema operacional você está usando. Na maioria dos casos, isso deve ser compatível com seus scripts v1; minhas colunas futuras assumirá que você estiver usando 2.0.
Don Jones * é um fundador da Concentrated Technology e perguntas respostas sobre o Windows PowerShell e outras tecnologias em * ConcentratedTech.com. Ele também é um autor para Nexus.Realtimepublishers.com, que muitos de seus livros torna disponível como edições eletrônicas gratuitas.
Conteúdo relacionado
· Windows PowerShell: De PowerShell e o Active Directory