PowerShell - ¿Qué versión ejecuto realmente? Evita errores

Comprobar la versión instalada de PowerShell evita errores tontos y ahorra tiempo cuando un script funciona en un equipo y falla en otro. En Windows, la confusión más común es mezclar Windows PowerShell 5.1 con PowerShell 7.x, porque conviven en paralelo y no siempre se abren desde el mismo acceso directo. Aquí te explico cómo ver la versión real que está ejecutándose, cómo interpretar la salida y qué revisar si el resultado no coincide con lo que esperabas.

Cómo comprobar la versión en segundos

Yo empiezo siempre por $PSVersionTable.PSVersion, porque me devuelve la versión del motor que realmente está corriendo en esa sesión, no la que creo haber abierto. Es la comprobación más directa y la más útil cuando quiero salir de dudas en menos de un minuto.

$PSVersionTable.PSVersion
pwsh -v

La primera orden funciona dentro de PowerShell y te muestra un número desglosado en Major, Minor, Build y Revision. La segunda sirve para comprobar desde consola, una tarea o un acceso directo qué versión de pwsh está instalada. Si quiero una vista más completa, escribo $PSVersionTable y miro también PSEdition, porque ahí aparece una pista clave sobre compatibilidad.

Con eso ya tienes la medición básica. El siguiente paso es entender qué significa realmente esa salida, porque ahí es donde suele empezar la confusión.

Qué significa la salida y por qué importa

La parte importante no es solo el número principal. En PowerShell, el dato que te interesa de verdad suele estar en dos sitios: la versión del motor y la edición. La versión te dice qué rama estás usando; la edición te aclara si estás en el mundo clásico de Windows PowerShell o en la línea moderna de PowerShell 7.

La propia documentación de PowerShell deja claro que $PSVersionTable describe la sesión actual, así que no conviene interpretar ese resultado como si fuera una ficha genérica del sistema. En la práctica, eso me recuerda una regla simple: la versión correcta no es la instalada en abstracto, sino la que está ejecutando el script en ese momento.

Con ese criterio en mente, la diferencia entre Windows PowerShell y PowerShell 7 deja de ser teórica y se vuelve operativa.

Windows PowerShell 5.1 y PowerShell 7 conviven, pero no hacen lo mismo

En Windows es habitual tener ambas líneas instaladas. Microsoft lo plantea así: PowerShell 7 no reemplaza a Windows PowerShell 5.1, sino que se instala aparte y puede convivir con él. Eso explica por qué una misma máquina puede abrir dos consolas distintas y dar dos respuestas diferentes al mismo comando.

Yo suelo mirar antes el nombre del ejecutable que el número, porque eso me dice qué ecosistema tengo delante. Si el comando es powershell.exe, sigo en la rama 5.1; si es pwsh.exe, estoy en PowerShell 7. Esa diferencia parece pequeña, pero cambia módulos disponibles, compatibilidad y comportamiento en varias tareas de automatización.

Y precisamente por eso conviene ajustar bien los scripts, sobre todo cuando no los vas a lanzar manualmente.

Cómo evitar confusiones en scripts y tareas automatizadas

En scripts y tareas programadas no me fío del acceso directo ni del icono. Si necesito una versión concreta, llamo al ejecutable correcto de forma explícita y, cuando el script depende de una rama mínima, lo declaro desde el principio.

#Requires -Version 6.0
#Requires -PSEdition Core

Ese bloque hace algo muy útil: detiene la ejecución antes de que el script entre en terreno peligroso. Si alguien intenta lanzarlo en una sesión demasiado antigua o en la edición equivocada, el fallo aparece de inmediato y no a mitad del proceso.

En tareas programadas o en CI/CD, yo prefiero escribir la ruta o el comando exacto que quiero usar. Si el flujo necesita PowerShell 7, llamo a pwsh.exe; si el módulo exige Windows PowerShell 5.1, asumo esa limitación y la documento. Lo que no hago es dejar que el sistema decida por mí, porque ahí nacen los errores más difíciles de reproducir.

Con eso cubres la parte preventiva. Falta la parte incómoda: qué revisar cuando el número que ves no encaja con lo que esperabas.

Qué revisar si la versión no coincide con lo que esperabas

Cuando la versión “sale mal”, casi siempre el problema está en qué shell has abierto, no en la instalación. Yo reviso primero esto, en este orden: el ejecutable, el acceso directo y la compatibilidad del módulo o del script.

Si necesitas depurar a fondo, también merece la pena comparar la ruta del binario que se está llamando. En muchos casos descubro que el sistema estaba usando una instalación vieja que seguía disponible en el PATH, aunque el usuario pensara lo contrario.

Eso me lleva a la comprobación mínima que yo haría antes de tocar un script importante.

La comprobación mínima que yo haría antes de tocar un script importante

Yo me quedo con tres gestos: comprobar la versión, comprobar la edición y fijar el ejecutable correcto. Con eso evito la mayoría de los fallos de compatibilidad en Windows, sobre todo cuando alterno entre scripts antiguos y automatizaciones nuevas.

• Uso $PSVersionTable.PSVersion para saber qué motor está activo.
• Uso PSEdition para distinguir entre Desktop y Core.
• Documento el mínimo con #Requires -Version cuando el script dependa de una rama concreta.
• Si voy a estandarizar equipos nuevos, lanzo pwsh de forma explícita y dejo powershell.exe solo para compatibilidad.

Si tengo que elegir una sola comprobación, hago la del hash table de versión: me da la respuesta real, sin depender de lo que diga el acceso directo ni de cuál de las dos instalaciones estaba en primer plano.