Corregir colores ANSI en la consola de Windows 10 tras la actualización Windows Anniversary

La actualización de Windows Aniversario por fin llegó a mi equipo y aunque en general parece ser más robusto y seguro, era imposible no encontrarse con nuevos fallos introducidos a causa de esta enorme actualización. No obstante por la curva de fallos real del software, en cada actualización se introducen nuevos fallos no existentes anteriormente o mal solventados.

curva_fallos_software

Obviamente en esta actualización no iba a ser menos, dado el calado tan ambicioso de la actualización. El fallo que he detectado se corresponde a la interpretación de los colores ANSI de la consola de Windows. Concretamente el problema reside en que no se procesan los códigos ANSI de escape, que antes estaba activado por defecto gracias al flag de la consola ENABLE_VIRTUAL_TERMINAL_PROCESSING.

Esto supone un problema para todas las librerías y códigos de Python que usaban los colores ANSI para cambiar de color la letra y fondo de la consola de manera trasnaprente en todos los sistemas.

Ejemplo de la problemática que se empieza a notar en algunas librerías:

https://github.com/pyreadline/pyreadline/issues/46

Ante este problema se me ocurrieron 2 formas de arreglarlo.

 


Solución 1


cmder-main

La primera pasa por añadir un frontend a la maltrecha consola de comandos de Windows y pensé en Cmder por ser un proyecto que además es portable. De esta forma con un lanzador .BAT/.CMD es posible lanzar sobre Cmder lo que queramos y dejar a un lado la problemática de los colores.

La solución consiste en descargar Cmder en su versión portable y añadir el siguiente .BAT que nos permita lanzar Cmder y ejecutar comandos en su inicio:

@echo off
set CMDER_ROOT=%~dp0
start %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.exe /icon "%CMDER_ROOT%\cmder.exe" /title Cmder /loadcfgfile "%CMDER_ROOT%\config\ConEmu.xml" /cmd cmd /k "%CMDER_ROOT%\vendor\init.bat cd %CD% && cd .. && %~1"

Este archivo que puedes llamar “cmder.bat” debe estar al mismo nivel de directorio que el ejecutable “Cmder.exe“. En este caso además se asume que Cmder está en una carpeta en la raíz del proyecto y la consola se posiciona en el nivel inmediatamente superior al que se encuentra “cmder.bat” y “Cmder.exe“.

La forma de usar “cmder.bat” asumiendo que está en la carpeta “cmder” sería la siguiente:

start /B cmder.bat "python main.py" ^&^& timeout 5 ^&^& exit

En este caso se lanza un programa en Python, cuyo archivo de ejecución principal es “main.py“. Con el parámetro “/B” se lanza la aplicación sin crear una nueva ventana. Adicionalmente se le indica con “^&^& timeout 5” que la consola espere 5 segundos antes de procesar la salida de la consola gracias a “^&^& exit”. El resultado sería algo similar a esto:

cmder-launch

 


Solución 2


La segunda solución pasa por añadir un parche en la librería de Python que usa colores ANSI o en su defecto en el “main” de la aplicación. Las líneas de Python que debes añadir para corregir el problema específico de la interpretación de los colores ANSI de la consola de Windows tras la actualización de Windows Aniversario, es la siguiente:

import os
import platform

if os.name == 'nt' and platform.release() == '10' and platform.version() >= '10.0.14393':
    # Fix ANSI color in Windows 10 version 10.0.14393 (Windows Anniversary Update)
    import ctypes
    kernel32 = ctypes.windll.kernel32
    kernel32.SetConsoleMode(kernel32.GetStdHandle(-11), 7)

Gracias a la librería ctype que proporciona tipos de datos compatibles con C, se pueden hacer llamadas a DLLs o librerías compartidas. Esencialmente lo que se hace es habilitar la flag ENABLE_VIRTUAL_TERMINAL_PROCESSING.

De esta forma los colores de la consola pasan de verse así:

ansi_win_before

A verse así:

ansi_win_after

¡Mucho mejor!, ¿no?

Dejo a continuación la referencia al Fix completo publicado en Gist de GitHub:

ANSIColorFix.py

 

Ambas soluciones resuelven la problemática del color ANSI en la consola de Windows tras la actualización Aniversario del sistema. No obstante la primera solución puede ser menos invasiva al no requerir de cambios en el código, pero la segunda es una solución de enfoque más nativo, ofreciendo una solución transparente a los desarrolladores que hacen uso de las librerías afectadas por este problema.

2188 Visitas Totales 2 Visitas para Hoy

Deja un comentario