Como cualquier lenguaje de programación, PowerShell soporta comentarios. De hecho, soportará dos estilos de comentarios. Sin embargo, como verás más adelante en este artículo, PowerShell puede utilizar los comentarios de un par de maneras interesantes e inesperadas que pueden ser bastante potentes.

Usando comentarios

El estilo más común de comentario que verás es una línea precedida por un símbolo #. (Te dejo a ti decidir si quieres llamar a eso un hashtag, un símbolo de libra, o incluso un buen octotoro.)

Como ejemplo, podrías tener un bloque de comentarios al principio de tu programa con detalles sobre el mismo:

1

.

2
3
4
5
6

#Este es un ejemplo de comentarios de una solalínea de comentarios
#
#Autor: Greg D. Moore [email protected]
#Fecha: 2019-11-12
#Versión: 1.0
#

Comentarios como este pueden ir en cualquier parte de tu código. Una forma alternativa de hacerlo, sin embargo, sería más lo que yo llamaría un estilo de lenguaje C o a veces referido como un comentario de bloque:

1
2
3

.

4
5

<#Este es un ejemplo de comentario en bloque
Autor: Greg D. Moore [email protected]
Fecha: 2019-11-12
Versión: 1.0
#>

Este estilo te permite añadir más fácilmente líneas de comentarios sin tener un # delante de cada uno. Eres libre de usar cualquiera de los dos estilos o incluso ambos. Sin embargo, recuerda la utilidad de los bloques de comentarios como este cuando vuelvas a depurar tu propio código dentro de un año. Sin embargo, los comentarios no tienen por qué ir al principio de una línea. De hecho, personalmente sólo utilizo bloques de comentarios como los anteriores al principio de un script o justo antes de un bloque de código especialmente complicado. Soy mucho más propenso a hacer comentarios al final de la línea como:

1
$Callback_Test_Form.Show() | Out-Null #absorbe el mensaje de cancelación al final. Esto ocurre por razones ajenas a este artículo

Incluí este comentario en un script reciente porque el | Out-Null no era algo que esperaba que fuera necesario, y sé que dentro de un año si no tuviera el comentario ahí me preguntaría por qué lo tenía ahí. O peor aún, lo quitaría y luego me preguntaría por qué me aparecía un mensaje de cancelación.

Nota que cuando empiezas un comentario con un #, todo hasta el final de la línea se trata como un comentario. Esto puede ser útil, por ejemplo, cuando estás probando y podrías querer comentar el final de un comando.

1
get-help write-host #Ooops, No quiero ir -online

Esto te permite luego eliminar el comentario y obtener la versión –online de la ayuda, pero ¿qué pasa si quieres un comentario en el medio? De nuevo, PowerShell te da ese poder.

1
get-help write-host <# Quiero el más reciente, así que iré #> -online

Nota que al usar un comentario de estilo bloque, obtienes la capacidad de tener un comentario en medio de tu comando y seguir ejecutando o interpretando los elementos a su derecha. Por último, puede que te preguntes: «¿y si quiero imprimir un # o hacer algo similar?». Si intentas

1
escribir-host Pulsa # en tu teléfono

Verás que no escribe lo que quieres. Simplemente obtienes:

Aquí es donde el acento grave ` es útil.

1
escribir-host Pulsa `# en tu teléfono

Esto imprimirá el mensaje que quieras.

También podrías envolver toda esa cadena entre comillas:

1
write-host ‘Pulse # en su teléfono’

Eso funcionaría, pero quería dar un ejemplo de cómo escapar del calificador #.

Si tú, como yo, utilizas a menudo el ISE de PowerShell para escribir scripts, hay un último truco útil que quiero compartir, pero que sólo puedo describir y dar algunas capturas de pantalla, no proporcionar realmente un script para ello. Se trata de un atajo de teclado que no es específico de los comentarios, pero que es útil si tienes un trozo de código que quieres comentar, por ejemplo para hacer pruebas. Coloca el cursor al principio de la línea y, manteniendo pulsada la tecla Shift-Alt, utiliza las flechas para moverlo hacia arriba o hacia abajo. Verás que aparece una línea fina (azul en mi pantalla). Una vez que hayas marcado las líneas que quieres comentar, simplemente escribe un # y aparecerá al principio de cada línea.

Este es un ejemplo del código a comentar:

Al hacer clic a la derecha del texto de la línea 40 y tras pulsar varias veces Shift-Alt y la flecha hacia arriba, verás la línea azul:

Tras pulsar # <space> verás los caracteres añadidos al código:

Como nota, puedes usar este truco en cualquier parte de la línea (así que si quisieras poner un montón de comentarios al final de varias líneas podrías usar este truco para poner fácilmente el # por ti) y obviamente no es específico para comentar, pero es uno de los usos más obvios. También puedes hacer esto usando expresiones regulares. Resalta el bloque de código en cuestión:

Entonces Ctrl-H para obtener el cuadro de diálogo Buscar y Reemplazar. Asegúrese de que las opciones Buscar en la selección y Expresiones regulares están seleccionadas:

El signo de intercalación ^ se utiliza para anclar el inicio de una línea y, por supuesto, el # (hay un espacio ahí) básicamente inserta un # y un espacio al final de las líneas resaltadas. Ten en cuenta que si no resaltas un bloque de código, esto operará en todo tu script.

Y más

Sin embargo, si eso fuera todo lo que los comentarios pueden hacer en PowerShell este sería un artículo muy corto y aburrido (y mi editora estaría moviendo la cabeza diciendo: «¡Greg, necesito más de 850 palabras!»). Como muchas cosas en PowerShell, los creadores agregaron características que lo hacen más poderoso de lo que uno podría esperar.

Recientemente me estaba preparando para una presentación que iba a dar en el Grupo de Usuarios de SQL Server de Hampton Roads. Durante esta presentación, ejecuto un script en PowerShell que inicia y detiene SQL Server. Para ello, tengo que ejecutarlo como administrador. Por supuesto, me había olvidado completamente de eso durante una práctica, y cuando lo ejecuté como yo mismo, terminó arrojando varios errores feos. Esto no fue un obstáculo, pero no es lo que quieres durante una demostración. Esto me hizo pensar en cómo podría asegurar que esto no ocurriera durante la charla real.

Mi primera idea fue encontrar algún cmdlet que comprobara con quién estaba conectado y luego abortara si no era el usuario correcto. Parte del problema con este enfoque, por supuesto, es que cuando se ejecuta un programa (como PowerShell ISE) como administrador, se muestra como el usuario conectado. Esto iba a ser más difícil de lo que pensaba.

Una vez más, PowerShell me sorprendió. Resolver este problema es trivial. Para ver cómo resolver el problema, abre el ISE de PowerShell como tú mismo (es decir NO seleccione Ejecutar como administrador y asegúrese de que su usuario no tiene privilegios de administrador local) e introduzca el siguiente código:

1
2

stop-servicio «windows time»
start-service «windows time»

Guarda esto en un archivo llamado ejemplo de servicio de temporizador de reinicio.ps1 y luego intenta ejecutarlo. A menos que seas un administrador local en tu máquina deberías obtener una pantalla de error similar a la de abajo.

Si ejecutas esto usando la opción Ejecutar como administrador, debería ejecutarse sin error. En este ejemplo, el fallo es bastante benigno, pero quizás estés escribiendo un script en el que un fallo no sería tan inofensivo. Para solucionar este problema, simplemente pon el siguiente comentario en la parte superior del script anterior y vuelve a guardarlo.

iv
#Requiere -RunAsAdministrator

Ahora obtendrás un error diferente:

Sigue siendo un poco feo pero mucho mejor que ejecutar el script y quizás romper algo. Ten en cuenta que si simplemente cortas y pegas el script en una nueva ventana, pero no lo guardas, PowerShell intentará ejecutarlo entero. Básicamente el #requires se ignora a menos que sea un archivo guardado real. Esto resolvió mi problema inicial, pero me llevó a buscar otras características que no conocía. Para #requires, hay una lista entera:

1
2
3
4
5
6

#Requiere -Versión N
#Requiere -PSEdition
#Requiere -PSSnapin PSSnapin-Name ]
#Requiere -Modules { Module-Name | Hashtable }
#Requires -ShellId ShellId
#Requires -RunAsAdministrator

Como puedes ver, esto te da mucho poder para controlar cómo y cuándo se ejecuta tu script. El #Requires –Version es útil si tu script requiere características que sólo están disponibles en una versión más reciente de PowerShell. Tenga en cuenta que este es un número mínimo. La versión de PowerShell que está ejecutando debe coincidir con esto o ser superior. No puede utilizarlo para requerir una versión anterior de PowerShell. Por ejemplo, un cmdlet útil que utilicé en un script reciente es compress-archive. Afortunadamente, este script era específico para el problema que estaba tratando de resolver, pero si estuviera tratando de escribir un script más general, podría poner #requires –Version 5.0 en la parada de mi script. Para demostrarlo guarda el siguiente script como requiere la versión example.ps1.

1
2
3

#requiere -Versión 5.0
Get-Proceso | Archivo de salida -Ruta de archivo .\Process.txt
Compress-Archive -Path .\Process.txt -DestinationPath .\Process.zip -Force

Si ejecuta esto dentro de su instancia de PowerShell ISE existente, debería ejecutarse sin problemas, pero si intenta ejecutarlo en una versión anterior, como PowerShell 2.0, la secuencia de comandos se error en el #requires línea y nunca ejecutar el resto de la secuencia de comandos. Este es el resultado deseado.

Para las pruebas, también podrías poner algo como –Version 99.99 y verás mensajes de error similares a los ejemplos de abajo, pero quería mostrar cómo funcionaría esto en el mundo real en los sistemas existentes y también demostrar la capacidad de la línea de comandos para volver a una versión anterior de PowerShell.

Para probar esto, tendrás que usar la versión de línea de comandos de PowerShell e iniciarla de la siguiente manera:

1
C:>Powershell -versión 2.0

Luego ejecuta el archivo que guardaste arriba requires version example.ps1. Deberías ver un error como:

Aunque yo recomendaría poner el comentario #Requires al principio del archivo, en realidad, puedes ponerlo en cualquier parte y actuará igual. Si vuelves a crear el archivo anterior pero mueves el comentario hacia abajo después del Get-Process y guardas como requiere la versión ejemplo Version 2.ps1.

1
2
3

Get-Proceso | Archivo de salida -Ruta de archivo .\Process.txt
#requires -Versión 5.0
Compress-Archive -Path .\Process.txt -DestinationPath .\Process.zip -Force

Intenta ejecutarlo bajo la versión 2.0 como la anterior, y obtendrás un error similar y todo el script fallará al ejecutarse.

Esto significa que no puedes tener una parte de un script que pueda ejecutarse bajo una versión anterior (o ejecutarse como no administrador) y luego una parte que requiera una versión concreta o ejecutarse como administrador. Si quieres hacer algo así en el código, tienes que ser más inteligente. Guarda el siguiente script como Requiere versión de ejemplo Versión 3.ps1.

1
2
3
4
5
6
7
8

Get-Process | Out-File -FilePath .\Process.txt
if ($PSVersionTable.PSVersion. Major -ge 5)
{
Compress-Archive -Path .\cess.txt -DestinationPath .\Process.zip -Force
}
else
{
Escribe-Host «Lo siento Dave, no puedo hacerlo».
}

Si ejecuta esto bajo la versión 5 o superior, creará el archivo Process.txt y lo comprimirá. Si lo ejecuta bajo una versión anterior, como la –Version 2.0 anterior, el script aún podrá crear el archivo Process.txt ya que Get-Process es un cmdlet disponible en la versión 2.0. Como Compress-Archive no lo está, el script se saltará ese paso y dará un mensaje de error. Depende de ti si quieres escribir scripts que detecten la versión de PowerShell y se comporten de forma diferente dependiendo de la versión, pero en muchos casos si simplemente quieres abortar el script, el comentario #Requires es, con diferencia, la forma más fácil de manejar las cosas.

Dos últimas advertencias sobre el uso de un comentario #Requires. Debe comenzar al principio de la línea; no puedes tener espacios o tabulaciones antes de él. Además, no puedes intentar ser más astuto y ponerlo como parte de un bloque try/catch para manejarlo con más gracia. Guarde el siguiente script para ilustrar ambas advertencias: Requiere la versión de ejemplo Versión 4.ps1.

1
2
3
4
5
6
7
8
9

#requiere -Version 5.0
intentar
{
escribir-host «¡Estamos en la versión 5.0!»
#requires -Version 5.0
}
catch
{
write-host «¡Hey, no estamos en la versión 5!»
}

Nota que es el #requires de la línea 6 el que abortó el script, no el de la línea 1, y el try/catch no tuvo efecto. Los #Requires son globales y afectan a todo el script, independientemente de dónde estén, siempre que empiecen en la línea. Y sí, puedes tener más de un #Requires en un script. Podrías requerir una versión específica de PowerShell, que ciertos módulos estén presentes y que RunAsAdministrator.

Dos advertencias finales sobre el comentario #Requires – RunAsAdministrator. Se introdujo en la versión 4.0 de PowerShell y no funciona en sistemas que no sean Windows (sí, recuerda, ¡PowerShell es ahora multiplataforma!). Guarde el siguiente script como Requires Administrator.ps1.Necesitará una instancia de Linux para probarlo, pero suponiendo que lo tenga, PowerShell puede ser instalado en Linux usando los métodos explicados aquí. Una vez instalado, copie o guarde el script anterior en su instancia de Linux. Para ejecutar el script puedes introducir:

1
Pwsh «./Requires Administrator.ps1»

Deberías ver

Por último, puede que te preguntes si puedes usar comentarios de estilo bloque con el #Requires. Desde mis limitadas pruebas, esto no funciona. Tienes que poner cada Requires en su propia línea con un # precedente. Este script funciona:

1
2

#Requiere -RunAsAdministrator
#Requiere -Versión 5.0

Este script no funciona:

1
2

<#Requiere -RunAsAdministrator
Requiere -Versión 5.0 #>

Conclusión

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *