Windows PowerShell: Definición de parámetros
Existen formas sencillas y formas complejas para definir parámetros en Windows PowerShell y ambas tienen sus ventajas.
Don Jones
Escribiré a menudo una secuencia de comandos o la función que necesita aceptar algún tipo de entrada. Esto podría ser un nombre de equipo, una ruta de archivo o algo así. Puede indicar a Windows PowerShell esperan estos parámetros, recogerlos desde la línea de comandos, y poner sus valores en variables dentro de la secuencia de comandos o la función. Hace tratar con entrada fácil y eficiente.
Sólo tienes que saber cómo declarar sus parámetros. El medio más simple de hacerlo es por lo que el bloque de param:
Param(
[string]$computerName,
[string]$filePath
)
No tienes dividir en líneas separadas como lo he hecho. Es legal para ejecutarlo todos juntos en una sola línea. Prefiero romper para facilitar la lectura, aunque. Cuando se utiliza como las primeras líneas de código en un archivo de script o dentro de una función, Windows PowerShell lee esto y serán nombres de parámetro incluso completar la ficha cuando alguien ejecuta el script o función. He procurado usar nombres de parámetro: son –computerName y –filePath aquí. Estos son similares a los que otros cmdlets de Windows PowerShell que se utilice para este tipo de información. De este modo, mis parámetros son consistentes con lo que ya está en la cáscara.
Si pongo esto en un script llamado Get-Something.ps1, utilizo los parámetros como este:
./Get-Something –computerName SERVER1 –filePath C:\Whatever
Yo también podría truncar los nombres de parámetro. Esto me permite escribir caracteres menos y todavía funcionan:
./Get-Something –comp SERVER1 –file C:\Whatever
Incluso podría omitir los nombres totalmente. Windows PowerShell automáticamente y posicionalmente aceptará valores. Aquí necesito tener cuidado proporcionar los valores en el mismo orden en que los parámetros aparecen en mi archivo:
./Get-Something SERVER1 C:\Whatever
Naturalmente, utilizando nombres de parámetros, el comando se vuelve un poco más fácil para una persona averiguar. Luego llego el lujo de poner los parámetros en cualquier orden deseado:
./Get-Something –filePath C:\Whatever –computerName SERVER1
Windows PowerShell también proporciona una manera más compleja de declarar parámetros. Esta sintaxis más completa le permite definir parámetros como obligatorio, especificar una posición (si no lo haces, entonces el parámetro puede ser utilizado por su nombre) y más. Esta sintaxis ampliada también es legal en secuencias de comandos y funciones:
[CmdletBinding()]
Param(
[Parameter(Mandatory=$True,Position=1)]
[string]$computerName,
[Parameter(Mandatory=$True)]
[string]$filePath
)
De nuevo, puede ejecutar todo lo que juntos en una sola línea, pero lo rompiendo hace un poco más fácil de leer. He dado tanto de mis parámetros un [Parameter()] decorador y ambos definidos como obligatorios.
Si alguien intenta ejecutar mi script y olvida de uno o ambos de estos parámetros, la shell solicitará automáticamente para ellos. No hay ningún trabajo extra de mi parte es necesario para que eso suceda. Yo también he define –computerName como en la primera posición, pero –filePath tiene que ser proporcionada por nombre.
Hay algunas otras ventajas de utilizar la Directiva de [CmdletBinding()]. Para uno, asegura mi script o función tendrá todos los Windows PowerShell parámetros comunes, incluyendo –Verbose y –Debug. Ahora, puedo usar escritura detallado y Write-Debug dentro de mi script o función, y su salida se eliminan automáticamente.
Ejecutar el script o función con –Verbose o –Debug y detallado de la escritura o Write-Debug (respectivamente) por arte de magia se activan. Es una buena forma de producir información de progreso paso a paso (escritura detallado) o agregar puntos de interrupción de depuración (Write-Debug) en los scripts.
Como actualmente está escrito, ambos parámetros aceptará sólo un único valor. Declararlas como [cadena [[]] les permitiría aceptar una colección completa de valores. Entonces se podría enumerar esto mediante un bucle Foreach, por lo que podría trabajar con un valor en un momento.
Otro tipo de parámetro neat es [conmutador]:
Param([switch]$DoSomething)
Ahora, puedo ejecutar mi script o función con ningún parámetro de –DoSomething e internamente la variable $ de DoSomething será $False. Si ejecuto el script con el parámetro –DoSomething, $DoSomething obtiene valor $True. No hay necesidad para pasar un valor al parámetro. Windows PowerShell pone $ True si es simplemente incluirlo. Se trata de cómo funcionan los parámetros del conmutador, como el parámetro –recurse de Get-ChildItem.
Tenga en cuenta que cada parámetro es su propia entidad, y se separa el parámetro siguiente por una coma. Usted notará en un ejemplo anterior:
[CmdletBinding()]
Param(
[Parameter(Mandatory=$True,Position=1)]
[string]$computerName,
[Parameter(Mandatory=$True)]
[string]$filePath
)
El parámetro –computerName todo, incluyendo su decorador [Parameter()], aparece antes de la coma. La coma indica que estoy hecho explicando el primer parámetro y estoy listo para pasar a la siguiente. Todo lo relacionado con –filePath sigue la coma. Si necesitaba un tercer parámetro, yo pondría otro coma:
[CmdletBinding()]
Param(
[Parameter(Mandatory=$True,Position=1)]
[string]$computerName,
[Parameter(Mandatory=$True)]
[string]$filePath,
[switch]$DoSomething
)
Todo eso está dentro del bloque Param(). Nota que no tienes que usar el decorador [Parameter()] en cada parámetro. Sólo utilícelo en los donde necesita declarar algo, como el parámetro siendo obligatoria, aceptando la tubería de entrada, estar en una posición determinada y así sucesivamente. Ejecutar about_functions_advanced_parameters de ayuda en Windows PowerShell para obtener más información sobre otros atributos que se pueden declarar de esa manera.
Escribir secuencias de comandos que aceptan la entrada sólo a través de los parámetros y funciones es una mejor práctica. Hace más autónomo, documento más fáciles y más coherente con la forma como el resto de las obras de shell.
.jpg)
Don Jones es un ganador del premio MVP de Microsoft y autor de "Aprender Windows PowerShell en un mes de comidas" (Manning Publications, 2011), un libro diseñado para ayudar a cualquier administrador de convertirse en efectivo con Windows PowerShell. Jones también ofrece capacitación de Windows PowerShell in situ y público. Contactar con él a través de ConcentratedTech.com o bit.ly/AskDon.