Cuidado que ($a -eq $a) no siempre es $true

Este es uno de esos ejemplos en los que es importante intentar documentarse todo lo posible al desarrollar en un lenguaje/plataforma que no conocemos. Es frecuente asumir conceptos basados en nuestros conocimientos previos de otros lenguajes, pero en ocasiones nos puede jugar malas pasadas. En este caso voy a mostrar un ejemplo muy sencillo en el que yo asumí erróneamente el funcionamiento de algo tan sencillo como un operador de comparación.

Este problema lo encontré desarrollando una prueba mientras practicaba TDD. Por hacerlo fácil, este es el ejemplo más simple que se me ocurre para describir lo equivocado que estaba:

$a = @("item1", "item2")
if ($a -eq $a) { Write-Host "$a es igual que $a" }
else { Write-Host "$a no es igual que $a" }

Asumiendo que -eq es el operador de igualdad, alguien que no conozca PowerShell pero si conozca otros lenguajes de programación podría asumir que este script de ejemplo entraría por el if en lugar de por el else. Mi error fue precisamente ese. Si ejecuto este script en powershell, pintará en pantalla “item1 item2 no es igual que item1 item2”.

Si me hubiera molestado en leer la documentación de PowerShell hubiera visto que el operador -eq es bastante peculiar y en realidad hace algo más complicado. Aunque recomiendo leer la fuente original, estes es un pequeño resumen:

• Si ambas variables son de tipo string, aplicará una comparación “case-insensitive” retornando $true o $false
• Si la de la izquierda es un array de strings @(“item1”, “item2”) y la de la derecha es un string “item1”, buscará si el array contiene “item1” y retornará @(“item1”)
• Si a la izquierda tenemos un array de strings @(“item1”, “item2”) y a la derecha un array de strings con un único item @(“item1”), retornará @(“item1”)
• Como ya hemos visto al principio, si tenemos un dos arrays de strings, aunque sean iguales, retornará @()
• Algunos ejemplos anteriores darán resultados distintos si invertimos las variables y cambiamos izquierda por derecha, si quieres saberlos, prueba! 😉

Conclusión, hay que leer más. Para mi es de mucha ayuda leer código de otros. Estudiar cómo están desarrollados Pester o Psake me ha permitido entender mucho mejor las bondades de PowerShell.

Publicado originalmente en el blog de Modesto San Juan.