Windows PowerShell: Uso compartido de las secuencias de comandos - simplificadas
Don Jones
Una limitación de Windows PowerShell v1 es que no hace mucho para hacer más fácil compartir la secuencia de comandos. Por supuesto, podría fácilmente copiar un archivo de script. ps1 en otro equipo, o incluso zip hacia arriba y enviarlo por correo electrónico a un colega, pero podría hacerlo con VBScript hace más de una década. Si la secuencia de comandos incluye funciones reutilizables, sin embargo, quien ha recibido de la tendría que saber cómo al punto origen, o podría concluir realmente tener que modificar para ejecutar esas funciones.
Después de todo, era una situación aceptable, incluso si no era ideal. La situación se convirtió en menos aceptable para secuencias de comandos suministrada por las vistas de formato personalizado o las extensiones de tipo, porque esos archivos adicionales se tenían que se va a cargar manualmente en el shell para ser utilizado por la secuencia de comandos.
Sin con Windows PowerShell v2, embargo, nos hemos moverse a una situación ideal casi gracias a la introducción de módulos.
Fragmentos autónoma de buenas de shell
A módulo es simplemente una colección de archivos que se relacionan entre sí. Hay dos amplias categorías de módulos: Binarios y secuencias de comandos.
A binario módulo se compone de uno o más archivos DLL, que se compilan desde un lenguaje de Microsoft .NET Framework como C# o Visual Basic. En los días v1, llamamos a estos PSSnapins y escribir realmente uno en Visual Studio no ha cambiado mucho. Complemento, sin embargo, requiere escribir también un instalador para registrar el archivo DLL con el shell. Con un módulo, no es necesario ninguna instalación. En su lugar, el módulo va acompañado por un archivo .psd1 — un módulo de manifiesto. El manifiesto es simplemente algunos XML que indica qué archivos DLL se debe cargar. El manifiesto también puede especificar archivos de extensión de tipo que lo acompaña (.ps1xml) o ver los archivos (. format.ps1xml).
Funciona de la siguiente forma: El módulo debe estar instalado en un subdirectorio dentro de la carpeta de Windows PowerShell \modules. De forma predeterminada, esto es c:\windows\system32\windowspowershell\v1.0\modules. Por lo tanto, un módulo denominado “ MyModule ” iría en c:\windows\system32\windowspowershell\v1.0\modules\mymodule y el archivo de manifiesto sería mymodule.psd1. Todos los archivos relacionados con el módulo normalmente haría agruparse en esa misma carpeta, manteniendo todo independiente.
Para cargar el módulo, simplemente ejecute Módulo de importación MyModule. El shell se busca en la carpeta \modules de forma predeterminada (aunque también se puede pasar una ruta de acceso completa al Módulo de importación si su módulo está ubicado en otro lugar), observa que un archivo .psd1 existe, lo lee y carga los archivos a los que hace referencia dentro de. Es fácil distribuir el módulo: Zip sólo copia los archivos y copie el archivo .zip a otro equipo, no es necesaria la instalación.
Rollo de sus propios módulos
¿Cómo realiza esta ayuda distribuir las secuencias de comandos más fácilmente? El segundo tipo de módulo, un módulo de secuencia de comandos, es la respuesta. Esto es simplemente un normal script de Windows PowerShell, con una extensión de nombre de archivo .psm1 en lugar de la extensión del nombre de archivo. ps1 habitual. Colocar mymodule.psm1 en la carpeta \modules le permite ejecutar Módulo de importación MyModule y la secuencia de comandos se ejecutarán.
Normalmente, un módulo de secuencia de comandos consiste en completamente de funciones. Es decir, cuando se importa el módulo, no hay nada realmente ejecuta, las funciones dentro del módulo de secuencia de comandos se cargan en el shell y estén disponibles en todo el shell. Suponga que tiene un módulo de secuencia de comandos tiene un aspecto similar al siguiente:
Function Get-Inventory {
# (some code goes here)
}
Function Test-Connectivity {
# (some code goes here)
}
Function Write-Inventory {
# (some code goes here)
}
Importación de este módulo haría Get-inventario, probar la conectividad and Inventario de escritura funciones disponibles en todo el shell de forma similar a los cmdlets (de hecho, el próximo mes, le mostraré cómo escribir una función que se comporta casi exactamente como un cmdlet “ real ”). Incluso pueden incluir las funciones de Ayuda basada en comentario (que he demostrado en Mi última columna), por lo que alguien se pudo importar el módulo y ejecutar Ayudar a Get-inventario para ver instrucciones para utilizar esa función.
A veces desea un poco de privacidad
A veces es posible que tenga un módulo de secuencia de comandos complicada que incluya funciones previstas para utilizarse sólo por otras funciones en vez de por un usuario. Por ejemplo, podría pretendo Prueba de conectividad and Inventario de escritura sea “ privada ” al módulo. Esto significa que se llamaría por Get-inventario pero no espere que puedan ser invocado directamente por un usuario del shell.
De forma predeterminada, Módulo de importación imports todo en el módulo que cada función visibles para el usuario de shell. Puede reemplazar dicho comportamiento especificando simplemente una lista de las funciones de tiene la intención sea visible; todo lo demás se se oculta al usuario de shell. Para ello, simplemente ejecutar Exportación ModuleMember al final de su módulo de secuencia de comandos:
Exportación ModuleMember –function get-inventario
También puede exportar los cmdlets, variables y alias que define la secuencia de comandos, si es necesario. Run Ayudan a exportar ModuleMember, or see Exportación ModuleMember para obtener más detalles.
Desventajas de módulo
Para mí, bummer sólo acerca de los módulos de v2 es que el shell parecía tener predeterminada sólo una ubicación para ellos, y dicha ubicación está bajo la carpeta del sistema de Windows, que no es algo que desea obtener el hábito de modificación. Pero, a continuación, he mirado la variable de entorno PSModulePath y descubrió que el shell también buscará en la carpeta de documentos en una subcarpeta denominada WindowsPowerShell\Modules, y ello donde ahora mantener todos los módulos que escribo.
En el futuro, también es posible que vea cmdlets diseñados para descargar los módulos adicionales de repositorios basados en Internet, no al contrario que la funcionalidad de pera utilizada en sistemas UNIX. Dichos cmdlets es más probable que descargar en la carpeta documentos o alguna otra ubicación que no sean del sistema operativo y tener el shell de buscar la carpeta de documentos para los módulos es un inteligente predeterminado.
Módulos, módulos, Everywhere
Debido a Don requieren instalación para poder ser “ visto ” por el shell, se utilizan módulos mucho más. De hecho, casi todas las extensiones de Windows PowerShell en Windows Server 2008 R2 se empaqueta como un módulo, la única excepción que se va a PSSnapin para automatizar la copia de seguridad de Windows Server (ejecutar Get-PSSnapin –registered para comprobar si está instalada en un servidor). Se incluye más código de terceros como módulos, demasiado, incluidos los cmdlets acceder al repositorio de código de la Comunidad en PoshCode.org.
De hecho, si es un usuario de Windows PowerShell especialmente grave interesado en escribir sus propios cmdlets pero no desea adentrarse en programación de .NET Framework en Visual Studio, la combinación de funciones avanzadas (de nuevo, que será columna del próximo mes) y módulos le ofrece la posibilidad de escribir su propio complemento “ shell ” por completo en la secuencia de comandos. Simplemente empaquetar sus funciones avanzadas: que busque y actúan como cmdlets: en una secuencia de comandos módulo y tiene una biblioteca de código reutilizable easy-to-distribute.
Windows PowerShell v2 ahora disponible para el público general
Aunque se realizó un envío preinstalado con Windows Server 2008 R2 y Windows 7, Windows PowerShell v2 y sus componentes de marco de administración complementario: ahora está disponible para Windows XP, Windows Server 2003, Windows Vista y Windows Server 2008. Sólo tiene que visitar support.Microsoft.com/kb/968929 para obtener el vínculo de descarga para cualquier sistema operativo está utilizando. En la mayoría de los casos, esto debe ser compatible con las secuencias de comandos v1; mis columnas futuras asumirá que usa 2.0.
Don Jones * es fundador de tecnología concentrado y preguntas respuestas sobre Windows PowerShell y otras tecnologías en * ConcentratedTech.com. También es un autor para Nexus.Realtimepublishers.com, que realiza muchos de sus libros disponibles como ediciones electrónicas gratuitas.
Contenido relacionado
· Windows PowerShell: PowerShell y Active Directory
· Windows PowerShell: Filtrar por un lado, dar formato por otro