Windows PowerShell: Scripts de PowerShell en comparación con los flujos de trabajo de PowerShell
Cada mes de este año, Don Jones presentará una entrega de un tutorial de 12 partes en flujo de trabajo de Windows PowerShell. Le recomendamos que lea la serie en orden, empezando por el enero 2013 columna.
Don Jones
Flujos de trabajo apariencia mucho como una función de Windows PowerShell o script, pero no. Su semejanza es sólo superficial, y no puede ser incluso completamente a través de la piel.
Hay que recordar que Windows PowerShell tiene flujos de trabajo se traducen en una tecnología totalmente separada, Windows Workflow Foundation (WF). Eso significa que sólo se pueden hacer las cosas que usted puede duplicar en WF. El código se ejecutará en un tipo diferente de medio ambiente que tiene sus propias reglas y restricciones. De hecho, las diferencias entre un flujo de trabajo y una escritura "normal" pueden ser significativas.
Un runspace frente a muchos
En una escritura normal, todo en el script funciona en una sola runspace, con una jerarquía de alcance único. Un runspace es equivalente a un proceso de Windows PowerShell. Si usted piensa en una ventana de consola de Windows PowerShell, es un solo runspace. Eso significa que todo es lo mismo, constante y persistente dentro de eso runspace.
Variables, comandos, unidades y todo lo demás todos comienzan una forma. Permanecen igual a menos que se modifiquen. Dentro de eso runspace, cualquier cambio que "pegar" para la duración de ese proceso.
En un flujo de trabajo, cada actividad, cada comando, bloque de script en línea y así sucesivamente, puede tener su propio runspace. Eso significa que si usted hace un cambio en uno, tal vez no sea visible en cualquier otro. Establecer una variable en una parte de su flujo de trabajo no podría hacer ningún cambio en otra parte del flujo de trabajo, a menos que usted tome medidas especiales para asegurar lo contrario.
Como ha visto en artículo del mes pasado, si se define una variable en el nivel superior del flujo de trabajo, existe en todo el flujo de trabajo (el sistema toma medidas para asegurarse de que esto es cierto). Si un comando dentro del flujo de trabajo crea una variable, esa variable no estará disponible para el resto del flujo de trabajo.
Esto significa el uso del módulo también es diferente. Importar un módulo en un momento dado no necesariamente hace comandos disponibles en un momento posterior. Necesita tener mucho más cuidado, porque un único flujo de trabajo esencialmente puede abarcar múltiples ámbitos independientes.
Diferencias sintácticas
Hay una serie de diferencias de sintaxis dentro de un flujo de trabajo, que algunos de los cuales yo he señalado en artículos anteriores de esta serie:
- Se pueden utilizar parámetros posicionales. Debe especificar cada parámetro del comando. Si estás acostumbrado a correr Dir C:\Windows, usted necesitará aprender –Path Get-ChildItem C:\Windows en su lugar. Usted puede todavía utilizar alias (por ejemplo, Dir) o truncado nombres de parámetro (por ejemplo, –Comput para –ComputerName).
- Flujos de trabajo pueden tener parámetros, pero sólo pueden incluir Letras, números, el subrayado y el guión en sus nombres. Es diferente de las reglas normales de secuencia de comandos de Windows PowerShell.
- Se puede importar un módulo en la sesión de flujo de trabajo. De hecho, comandos no pueden realmente cambiar el actual período de sesiones y tienen un efecto en los comandos. Si un flujo de trabajo debe usar un módulo, necesita usar el parámetro de la actividad de –PSRequiredModules.
- Por los comandos que tienen implementaciones de actividad de flujo de trabajo y actividad de JSON, obtendrás un montón de parámetros de comandos adicionales, incluyendo el parámetro de –PSRequiredModules mencionado anteriormente.
- No se puede ejecutar métodos de objetos en un flujo de trabajo, a menos que hacerlo dentro de un bloque de script en línea. El objeto debe ser producido dentro del bloque de secuencias de comandos en línea para el método de trabajo.
- No puedes scripts punto fuente.
- Se puede utilizar el operador "&" de invocación.
- Interruptor construcciones deben incluir el parámetro –CaseSensitive. El equivalente de flujo de trabajo de la construcción del interruptor es nativamente entre mayúsculas y minúsculas. Declaraciones del interruptor deben utilizar constantes. Se puede utilizar operadores de comparación, expresiones regulares, referencias de archivo o bloques de script. Básicamente, tratar de evitar construcciones del interruptor.
- No pueden romper y declaraciones de continuar.
- Sólo PSDrives Añadida por proveedores de base de Windows PowerShell, archivo de sistema, registro, almacén de certificados, medio ambiente, función, variable y WS-Management — son válidos. Para utilizar un PSDrive creado por un módulo, ejecutar la actividad con un parámetro de –PSRequiredModules y especifique el nombre del módulo.
sí, eso es un montón de diferencias. Si eres un programador de Windows PowerShell cuidado, te toparás con menor cantidad de ellas, como nombrar sus parámetros. Todavía te vas a encontrar diferencias que olvidó hasta que realmente te familiarices con flujos de trabajo de la escritura.
Bonos
Flujo de trabajo de Windows PowerShell no todas las diferencias de malas noticias — de hecho, le da un montón de funcionalidad gratis. Cada flujo de trabajo gana parámetros incorporados, incluyendo:
- –AsJob ejecuta el flujo de trabajo como un trabajo de fondo. Usted puede darle un nombre de trabajo mediante el uso de –JobName.
- –PSComputerName ejecuta el flujo de trabajo en el equipo designado o equipos, utilizando el entorno remoto de Windows PowerShell.
- –PSCredential y una variedad de parámetros relacionados permiten especificar los datos de autenticación alternativo.
- –PSPort y otros parámetros relacionados con la conexión permiten especificar detalles de la alternativa de conectividad para el componente de remoting de flujo de trabajo.
¿Observe un número de estos parámetros comienzan con –PS? Ha pedido un espacio de nombres. Evite crear sus propios parámetros que también comienzan con –PS. Si una versión futura de Windows PowerShell agrega nuevos parámetros, probablemente a empezar con –PS. Si generalmente evita que el prefijo a evitar colisiones con sus propios nombres de parámetro.
No peor, no mejor, pero diferentes
El resultado práctico aquí es que los flujos de trabajo no son scripts de Windows PowerShell. Son diferentes. Tienen algunas diferencias que pueden hacer su vida más fácil. Algunas otras diferencias pueden requerir un poco más trabajo de usted. Conocer las diferencias puede ayudar más rápidamente comenzar a escribir los flujos de trabajo eficaces.
.jpg)
Don Jones es un recipiente del premio MVP de Windows PowerShell y un editor colaborador de TechNet Magazine*.*Él ha coautor de cuatro libros sobre Windows PowerShell versión 3, incluso gratis en Windows PowerShell remoting y crear informes HTML en Windows PowerShell. Encontrarlos todos en PowerShellBooks.com, o hacer preguntas de Jones en los foros de discusión en PowerShell.org.