Windows PowerShell: Empaquetar y distribuir herramientas personalizadas de Windows PowerShell
Se pueden lograr algunas resultados muy interesantes con los scripts prefijados por puntos, pero esto mismo también puede traer algunas limitaciones si no se hace con cuidado.
Don Jones
Un punto de origen es un buen truco, pero puede resultar difícil quitar los comandos más adelante si no necesita o no más tarde, averigua que estén en conflicto con otra cosa. Después de que se activa un comando en un independientes, reutilizable, con parámetros de herramienta el mes pasado, he encontrado dos limitaciones que necesitamos para la dirección.
Hemos creado la herramienta como una función avanzada de Windows PowerShell, que a veces también se denomina "cmdlet de secuencia de comandos". El primer problema es que la secuencia de comandos es un poco difícil de utilizar. La secuencia de comandos contiene una función, sólo tendrá que ejecuta la secuencia de comandos no que nada ocurra. Tendrá que modificar la secuencia de comandos y los comandos necesarios para ejecutar la función o tienes a un punto de origen en el shell, la secuencia de comandos que hace la función disponible como comando global.
El segundo problema es que la secuencia de comandos incluye dos funciones. La primera de ellas, Get-OSInfo, es el que deseo de que se use. El segundo, OSInfoWorker, realiza todo el trabajo real. Sin embargo, que no es el que deseo ejecutar directamente. Con un punto de origen, no hay ninguna manera de ocultar OSInfoWorker (o márquelo como privado, en términos de programador). Hacer que la secuencia de comandos en un módulo de secuencia de comandos, se abordarán ambos problemas.
Sentido de módulos
Windows PowerShell admite tres tipos básicos de módulos: binario, la secuencia de comandos y módulos de manifiesto. Un módulo binario está formado por un archivo DLL que generó en Visual Studio que agrega los cmdlets, proveedores y otros elementos al shell. Un módulo de secuencia de comandos es simplemente eso: una sola secuencia de comandos que puede agregar una o varias funciones para el shell. Un módulo del manifiesto realmente puede incluir varios componentes, como las extensiones binarios, secuencias de comandos y así sucesivamente. Los módulos de secuencia de comandos son las más fáciles de crear, por lo es lo que vamos a utilizar.
Existen tres requisitos para un módulo de secuencia de comandos:
- Debe ser una secuencia válida de Windows PowerShell, que conste principalmente de las funciones que se agregará al shell.
- Debe tener una extensión de nombre de archivo de .psm1, en lugar de ps1.
- Se debe estar ubicado en una carpeta determinada en el equipo
Este último requisito es más de una sugerencia por motivos de comodidad. Tras la instalación, Windows PowerShell define una nueva variable de entorno de sistema llamada PSModulePath. Esto funciona mucho al igual que la variable de entorno Path del sistema. Contiene las carpetas que se busca automáticamente en el shell para buscar los módulos por nombre.
Hay dos rutas de acceso de módulo definidos de forma predeterminada. Uno es bajo la jerarquía de la carpeta System32. Éste está pensada para módulos proporcionados por Microsoft. El otro está en la carpeta documentos y está pensado para sus propios módulos. Utilizaremos esta otra. Puede, por supuesto, modificar o agregar a PSModulePath, tal vez define una central que su equipo se utiliza para almacenar los módulos compartidos.
La ruta de acceso que utilizaremos es \[My] Documents\WindowsPowerShell\Modules. En Windows XP, se etiqueta como Mis documentos. En Windows Vista y posterior, es sólo de documentos. No existe la carpeta WindowsPowerShell de forma predeterminada. Tendrá que crear que uno. También la subcarpeta módulos no existe de forma predeterminada, por lo que necesitará crear también.
La alternativa para colocar el módulo en una de las ubicaciones de PSModulePath es simplemente especificar una ruta de acceso completa y el nombre de archivo cuando se carga un módulo. Creo que sea menos cómodo con frecuencia utiliza módulos, por lo que Tiendo a quedarme con las rutas definidas en PSModulePath.
Hacer que un módulo
Voy a agregar tres comandos a la parte inferior de la secuencia de comandos del mes pasado (puede descargar la secuencia de comandos revisada aquí):
New-Alias goi Get-OSInfo
Export-ModuleMember -function Get-OSInfo
Export-ModuleMember -alias goi
El primer comando define un alias, "goi". Esto es para mi función Get-OSInfo. Los dos comandos sólo son efectivos cuando se utilizan dentro de un módulo de secuencia de comandos.
De forma predeterminada, cuando se carga un módulo en el shell, todas las funciones dentro de ese módulo estará disponible. Si se usa el ModuleMember de exportación, sin embargo, sólo aquellos funciona y alias, que explícitamente se denominan se ponen a disposición.
Mi alias de "goi", así como la función Get-OSInfo, debe ser visible para cualquiera que use este módulo. La función que no especifiqué, OSInfoWorker, se ocultará. Todavía puede utilizar cualquier función para llamar a OSInfoWorker en el propio módulo, pero no estará directamente accesible, ya que es una función privada.
Con estos comandos agregados, tengo que dar un nombre propio de la secuencia de comandos y la coloca en el lugar correcto. Supongamos que se elige un nombre de este módulo "mymodule". Esto significa que el archivo de secuencia de comandos debe ir en \[My] Documents\WindowsPowerShell\Modules\MyModule\MyModule.psm1.
La secuencia de comandos que se tiene que ir en una subcarpeta de módulos. La subcarpeta y en el propio archivo de secuencia de comandos deben llevar el nombre del módulo. Con esto se lleva a cabo, puedo ejecutar Import-Module MyModule para cargar el módulo.
Se trata de una manera fácil y eficaz para distribuir las secuencias de comandos a otros usuarios. ¿Puedo incluir tantas funciones y alias como desee dentro de este único archivo. A continuación, siempre que se encuentra en el lugar adecuado (o alguien está dispuesto a especificar su ruta de acceso completa), es fácil de otros usuarios para cargar el módulo y utilizar esas funciones.
.jpg)
Don Jones es fundador de la tecnología de concentrado y preguntas respuestas sobre Windows PowerShell y otras tecnologías de la ConcentratedTech.com. También es un autor de Nexus.Realtimepublishers.com, lo que muchos de sus libros disponibles como libres ediciones electrónicas a través de su sitio web.
Obtener el máximo partido
Descargar código de ejemplo que se relaciona con un artículo de este mes.
Finalice el tiempo para registrarse en live, exclusivo, práctico tres días taller Jones coincidir con la primavera de TechMentor 2011. Visite TechMentorEvents.compara obtener más información.