Windows PowerShell: Empacotar e distribuir Custom Windows PowerShell Tools
Você pode fazer algumas coisas interessantes com o ponto de origem, mas que também podem levar a certas limitações se você não tiver cuidado.
Don Jones
Ponto de origem é um truque, mas pode ser difícil remover comandos posteriormente, se você não precisar deles ou descobrir mais tarde estão em conflito com outra coisa. Depois que procuramos um comando em um autônomo, ferramenta reutilizável e parametrizada no mês passado, descobri duas limitações, precisamos comentar.
Criamos a ferramenta como uma função avançada do Windows PowerShell, que é também chamada "cmdlet do script". O primeiro problema é que o script é um pouco difícil de usar. O script contém uma função, portanto, basta executar o script não faz nada acontecer. Você tem que modificar o script e adicione os comandos necessários para executar a função, ou você tiver a fonte do ponto do script em shell, disponibilizando a função como um comando global.
O segundo problema é que o script incluído duas funções. A primeira, Get-OSInfo, é aquele desejo que as pessoas o utilizem. O segundo, OSInfoWorker, faz todo o trabalho real. No entanto, que não é o desejo que você execute diretamente. Usando o ponto de origem, não há nenhuma maneira de ocultar OSInfoWorker (ou torná-lo em particular, em termos de programador). Tornar o script em um módulo de script para abordar os dois problemas.
Faz sentido de módulos
O Windows PowerShell oferece suporte a três tipos básicos de módulos: binário, script e módulos de manifesto. Um módulo binário consiste em uma DLL compilada no Visual Studio adiciona cmdlets, provedores e outros elementos para o shell. Um módulo de script é exatamente isso: um único script pode adicionar uma ou mais funções para o shell. Um módulo de manifesto, na verdade, pode incluir vários componentes, como, por exemplo, extensões de binárias, scripts e assim por diante. Os módulos de script são mais simples de criar, isso é o que usaremos.
Há três requisitos para um módulo de script:
- Ele precisa ser um script Windows PowerShell válido, consiste principalmente em funções que serão adicionadas ao shell.
- Ele deve ter uma extensão de nome de arquivo de .psm1, em vez de. ps1.
- Ele deve estar localizado em uma pasta específica no seu computador.
Essa última exigência é realmente mais uma sugestão para fins de conveniência. Durante a instalação, o Windows PowerShell define uma nova variável de ambiente de todo o sistema, chamada PSModulePath. Isso funciona muito como a variável de ambiente Path do sistema. Ele contém as pastas que o shell automaticamente procura para localizar os módulos por nome.
Há dois caminhos de módulo definidos por padrão. Uma é sob a hierarquia de pasta System32. Este destina-se aos módulos fornecido pela Microsoft. O outro está na sua pasta de documentos e destina-se para seus próprios módulos. Usaremos esta. Você pode, obviamente, modificar ou adicionar a PSModulePath — talvez definindo um caminho central que sua equipe usa para armazenar módulos compartilhados.
O caminho que usaremos é \[My] Documents\WindowsPowerShell\Modules. No Windows XP, ele é rotulado como Meus documentos. No Windows Vista e posterior, é apenas documentos. A pasta WindowsPowerShell não existe por padrão. Você terá de criar um. A subpasta de módulos também não existe por padrão, portanto, você precisará criar que também.
A alternativa de colocar o seu módulo em um dos locais de PSModulePath é simplesmente especificar um caminho completo e nome do arquivo quando você carrega um módulo. Acho que seja menos conveniente para freqüentemente usado módulos, portanto, eu tendem a ficar com caminhos definidos no PSModulePath.
Tornando um módulo.
Vou adicionar três comandos na parte inferior do script do mês passado (você pode baixar o script revisado aqui):
New-Alias goi Get-OSInfo
Export-ModuleMember -function Get-OSInfo
Export-ModuleMember -alias goi
O primeiro comando define um alias, "goi". Esta é minha função Get-OSInfo. Os dois comandos são eficazes apenas quando você usá-los dentro de um módulo de script.
Por padrão, quando você carrega um módulo no shell, cada função dentro desse módulo é disponibilizada. Quando você usa ModuleMember de exportação, no entanto, somente as funções — e aliases — que são explicitamente nomeados são disponibilizadas.
Meu alias de "goi", bem como a função Get-OSInfo, deve ser visível para todos os usuários deste módulo. Não especifiquei a função OSInfoWorker, ficará oculta. Você pode usar qualquer função para chamar OSInfoWorker dentro do próprio módulo, mas não será acessível diretamente, pois é uma função privada.
Com esses comandos adicionados, eu preciso dê um nome apropriado para o script e colocá-la no lugar certo. Digamos que eu escolher nomear este módulo "para MyModule". Isso significa que o arquivo de script precisa ir no \[My] Documents\WindowsPowerShell\Modules\MyModule\MyModule.psm1.
O script deve entrar em uma subpasta de módulos. A subpasta e o arquivo de script devem conter o nome do módulo. Isso feito, é possível executar o Import-Module MyModule carregar meu módulo.
Esta é uma maneira fácil e eficiente de distribuir os scripts para outros usuários. Pode incluir tantas funções e aliases como desejo dentro desse arquivo único. Enquanto ele está localizado na posição correta (ou alguém está disposto a especificar o caminho completo), é fácil para os outros usuários carregar o módulo e usar essas funções.
.jpg)
Don Jones é dos fundadores da Concentrated Technology e respostas de perguntas sobre o Windows PowerShell e outras tecnologias de ConcentratedTech.com. Ele também é autor de Nexus.Realtimepublishers.com, que disponibiliza muitos dos seus livros como livres edições eletrônicas por meio de seu site.
Obtenha mais
Download código de exemplo que acompanha o artigo deste mês.
Tempo está se esgotando para registrar Jones prático ao vivo, exclusivo, três dias workshop co-localizado TechMentor Spring 2011. Visite TechMentorEvents.compara obter detalhes.