Domina Windows Terminal: perfiles, fuentes y atajos

Un modelo mental práctico: Terminal es un anfitrión, los perfiles son contratos

Piensa en Windows Terminal como un multiplexor bien portado con opiniones. No “es” PowerShell o WSL; los aloja. Tu trabajo es definir los contratos: qué shell arranca, con qué directorio de trabajo, bajo qué entorno, con qué fuente y atajos, y con qué barandillas de seguridad.

Si tratas los perfiles como decorativos (“solo haré clic en el desplegable”), acabarás con el mismo modo de fallo que un runbook SRE descuidado: ambigüedad bajo presión. Los perfiles deberían responder estas preguntas sin que pienses:

• ¿En qué entorno estoy: producción, staging, personal, on-call?
• ¿Qué identidad estoy usando: usuario local, admin, clave SSH A o B?
• ¿Cuál es el directorio por defecto y la cadena de herramientas por defecto?
• ¿Qué características de seguridad están activadas: confirmaciones, montajes solo lectura, avisos?

Esto no es estética. Es corrección operativa. El terminal es la cabina. Etiqueta tus interruptores.

Hechos interesantes y contexto útil para discusiones

1. Windows Terminal es relativamente nuevo: Microsoft lo presentó públicamente en 2019, y se volvió predeterminado en muchos equipos con Windows 11 después. El punto: sigue evolucionando; tu memoria de “antes funcionaba” puede depender de versiones concretas.
2. ConPTY fue el punto de inflexión: el Pseudo-terminal de Consola de Windows (ConPTY) permitió que las apps modernas de terminal hablaran con programas de consola de forma más parecida a Unix. Antes de eso, la emulación de terminal en Windows era… formadora de carácter.
3. El viejo Console Host (conhost.exe) sigue presente: Windows Terminal puede alojar aplicaciones de consola clásicas, pero pueden comportarse como si fueran de otra era, porque lo son.
4. PowerShell tiene dos personalidades: Windows PowerShell (5.1) es la versión heredada; PowerShell (7+) es multiplataforma y se desarrolla activamente. Mezclarlos sin etiquetar tu perfil es una trampa evitable.
5. WT admite múltiples renderizadores: el renderizado de texto acelerado por GPU puede ser rápido, pero también expone problemas de fuentes y glifos que no veías en consolas antiguas.
6. Las pestañas y paneles no son solo adorno: reducen el cambio de contexto. Usados mal, generan errores de “¿dónde estoy?”. Usados bien, convierten la respuesta a incidentes en un flujo repetible.
7. La configuración dejó el mundo JSON-only: al principio Windows Terminal se configuraba principalmente vía settings.json; ahora hay una UI, pero JSON sigue siendo la fuente de verdad para configuraciones reproducibles.
8. Las NERD fonts no son “un tema”: son fuentes parcheadas con glifos extra. Si no necesitas esos glifos, no necesitas la fuente—y reduces una clase entera de rarezas de renderizado.

Perfiles: haz que los entornos sean aburridos a propósito

Reglas de diseño de perfiles que previenen errores reales

Aquí están las reglas que aplico en equipos:

• Nombra los perfiles como nombras infraestructura: “WSL Ubuntu” está bien para un portátil. Para trabajo serio: “WSL: ubuntu (staging tooling)”, “PowerShell 7 (admin)”, “SSH: bastion (prod-readonly)”.
• El directorio por defecto es una política, no una preferencia. Empieza en un lugar seguro con scripts conocidos, no en el último directorio aleatorio al que hiciste cd.
• Haz que producción sea visualmente distinta. Diferente esquema de color, título de pestaña e incluso estilo de cursor. Quieres que tu cerebro lo note.
• Prefiere commandlines explícitos frente a “lo que encuentre el sistema”. Fija pwsh.exe vs powershell.exe, y fija distribuciones WSL por nombre.
• Usa un solo lugar para automatización: guarda los scripts de perfil en dotfiles versionados cuando sea posible. La magia local es cómo se crean las máquinas de nieve.

Estructura de configuración que se mantiene manejable

La configuración de Windows Terminal es una fusión de valores por defecto y tus sobrescrituras. No necesitas reescribir todo. Necesitas definir: perfil por defecto, lista de perfiles, valores de apariencia y bindings. Trátalo como infraestructura como código: mínimo, explícito y revisable.

Campos clave que debes entender y usar deliberadamente:

• defaultProfile: lo que se inicia al abrir Terminal. Si no lo estableces, tendrás sorpresas tras instalaciones y actualizaciones.
• profiles.list: tus definiciones curadas de perfiles.
• guid: la identidad estable de un perfil. Si editas perfiles solo por nombre, acabarás colisionando con los generados automáticamente.
• commandline: exactamente lo que arranca. Prefiere rutas explícitas para shells no incluidos.
• startingDirectory: el primer lugar al que llega tu shell. Lo aburrido es bueno.
• tabTitle y name: uno es la etiqueta visible, el otro es el selector de perfil. Usa ambos.
• colorScheme, cursorShape, font: barandillas visuales de seguridad.

Patrones de perfil que funcionan en producción

Patrón 1: “Admin” es un perfil separado. No confíes en “Ejecutar como administrador” como hábito. Quieres un perfil que claramente diga “estás sujetando la motosierra.” Icono distinto, esquema distinto, título distinto. Úsalo con intención.

Patrón 2: “Prod” es solo lectura por defecto. Si tu flujo lo tolera, usa un perfil SSH que te deje en un bastion con permisos restringidos, o un shell que exporte variables guardarraíles. Haz que “romper el vidrio” sea un perfil separado con un nombre obvio.

Patrón 3: Perfiles “Tooling” por contexto. Si tienes contextos de Kubernetes, perfiles AWS o diferentes configs SSH, no los cargues todos en cada inicio de shell. Crea perfiles que carguen lo que necesiten. El tiempo de inicio importa; la corrección también.

Fuentes: legibilidad, ligaduras y la tiranía de los glifos faltantes

Elige una fuente como eliges un dashboard de monitoreo

La fuente de tu terminal no es una declaración de moda. Es una interfaz. Tu elección de fuente afecta:

• Qué tan rápido detectas un typo en un comando que puede borrar cosas.
• Si los caracteres de dibujo de caja se muestran correctamente (piensa: tablas, UI tipo tmux, CLIs).
• Si los símbolos Powerline o Nerd Font aparecen como cuadrados.
• Si el renderizador GPU se esfuerza (raro, pero real en sistemas antiguos).

Mi consejo opinado:

• Por defecto usa Cascadia Mono u otra fuente monoespaciada y limpia que renderice bien en Windows. Manténlo aburrido hasta que tengas una razón para no hacerlo.
• Usa una Nerd Font solo si necesitas glifos. Si tu tema de prompt depende de íconos, vale. Si solo quieres sentirte moderno, no. Los glifos faltantes son ruido operativo.
• Desactiva las ligaduras salvo que tengas preferencia fuerte. Las ligaduras pueden hacer que operadores se malinterpreten como !=, => o == en ciertas fuentes. Cuando estás cansado, quieres literalidad.

Primera broma corta: Las ligaduras son como la cafeína—geniales hasta que te das cuenta de que ocultan la verdad y ahora no puedes dormir.

Problemas de fuente que parecen “el sistema está maldito”

Si ves cuadrados, signos de interrogación o símbolos de prompt desalineados, casi siempre es uno de estos:

• Elegiste una fuente sin los glifos Unicode necesarios.
• Tu shell emite símbolos Powerline pero tu fuente no está parcheada.
• Se están usando fuentes de fallback de forma inconsistente porque la fuente primaria carece de caracteres.
• Las métricas de la fuente causan problemas de altura de línea; el cursor no se alinea o el texto se superpone.

La solución rara vez es “reinstalar Windows Terminal.” Es “elige una fuente que coincida con tu prompt.”

Atajos: la memoria muscular vence a la creatividad

Asigna atajos para respuesta a incidentes, no por diversión

Los keybindings son donde los buenos usuarios de terminal se vuelven rápidos. Pero atajos aleatorios son peores que ninguno; generan falsa confianza. Elige un conjunto pequeño y estandarízalo en tus máquinas.

Mi filosofía recomendada para bindings:

• Mantén los valores por defecto cuando sean sensatos. Los valores predeterminados de Windows Terminal son en su mayoría razonables para pestañas/paneles.
• Estandariza los splits de panel a las mismas teclas que usas en otros multiplexores si vives en ellos. La consistencia vence la novedad.
• Haz que “copiar” y “pegar” sean predecibles. Decide si la selección copia automáticamente, si el botón derecho pega, y qué hace Ctrl+V. Luego aplícalo.
• Tener un comportamiento de “cerrado de pánico” que muestre un aviso. Cerrar la pestaña equivocada en medio de un incidente es un dolor especial.

Pestañas, paneles y el modo de fallo “panel equivocado”

Los paneles son maravillosos hasta que no lo son. El modo de fallo operacional central es ejecutar un comando en el panel equivocado. La cura no es “tener más cuidado.” La cura es:

• Títulos de pestaña distintivos que incluyan marcadores de entorno.
• Esquemas de color por entorno.
• Atajos de teclado para “enfocar panel” que sean fáciles y consistentes.
• Comandos de inicio que establezcan un prompt o título visible por entorno.

Tareas prácticas: 12+ comprobaciones, comandos, salidas y decisiones

Estas son tareas reales que puedes ejecutar en una máquina Windows con WSL instalado. Uso WSL porque nos da un shell consistente para comandos y salidas, y porque los usuarios modernos de Windows Terminal suelen tenerlo. Cada tarea incluye: el comando, qué significa la salida y la decisión que tomas.

Tarea 1: Verificar que Windows Terminal esté instalado e identificar el paquete

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-AppxPackage Microsoft.WindowsTerminal | Select-Object Name, Version, PackageFullName"
Name                          Version      PackageFullName
----                          -------      ---------------
Microsoft.WindowsTerminal     1.21.3471.0  Microsoft.WindowsTerminal_1.21.3471.0_x64__8wekyb3d8bbwe

Qué significa: Ves el paquete de Windows Terminal instalado y su versión.

Decisión: Si esto falta o es muy antiguo, deja de depurar ajustes. Actualiza primero; el comportamiento cambia entre versiones.

Tarea 2: Localiza la ruta del archivo de configuración que realmente editas

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Test-Path $p; $p"
True
C:\Users\cr0x\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

Qué significa: El archivo de configuración existe en la ubicación canónica para apps empaquetadas.

Decisión: Si Test-Path es False, puedes estar en otro canal de instalación o el archivo aún no se creó. Abre Terminal una vez, o encuentra la carpeta de paquete correcta.

Tarea 3: Valida que settings.json sea JSON válido (detecta comas finales rápido)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Get-Content $p -Raw | ConvertFrom-Json | Out-Null; 'JSON OK'"
JSON OK

Qué significa: Tu archivo de settings se parsea. Si no, Terminal puede ignorar partes silenciosamente o volver a valores por defecto según la falla.

Decisión: Arregla el JSON antes de tocar otra cosa. JSON inválido hace que cualquier otro síntoma parezca aleatorio.

Tarea 4: Lista perfiles y sus GUIDs para evitar editar el equivocado

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; $j.profiles.list | Select-Object name, guid, source"
name                    guid                                   source
----                    ----                                   ------
PowerShell              {61c54bbd-c2c6-5271-96e7-009a87ff44bf} Windows.Terminal.PowershellCore
Windows PowerShell      {0caa0dad-35be-5f56-a8ff-afceeeaa6101} Windows.Terminal.Powershell
Ubuntu                  {2c4de342-38b7-51cf-b940-2309a097f518} Windows.Terminal.Wsl

Qué significa: Tienes múltiples sabores de PowerShell además de WSL. Los GUIDs son los identificadores estables.

Decisión: Elige el que quieres cambiar y apúntalo por GUID, no por conjeturas.

Tarea 5: Comprueba cuál perfil es actualmente el predeterminado

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; (Get-Content $p -Raw | ConvertFrom-Json).defaultProfile"
{61c54bbd-c2c6-5271-96e7-009a87ff44bf}

Qué significa: Terminal abrirá PowerShell 7 por defecto (en este ejemplo, GUID mostrado).

Decisión: Establece el perfil por defecto explícitamente para que coincida con tu flujo de trabajo seguro más común. No dejes esto al azar.

Tarea 6: Inspecciona dónde inicia el perfil (startingDirectory)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; ($j.profiles.list | Where-Object name -eq 'PowerShell').startingDirectory"
C:\Users\cr0x

Qué significa: Tu perfil PowerShell abre en tu home de usuario.

Decisión: Si haces trabajo de ops, considera iniciar en un C:\ops o en una carpeta de repos con scripts y notas. Menos momentos de “¿dónde está ese archivo?”.

Tarea 7: Identifica qué shell se está ejecutando realmente (pwsh vs powershell)

cr0x@server:~$ powershell.exe -NoProfile -Command "$PSVersionTable.PSVersion.ToString()"
5.1.22621.2506

Qué significa: Este comando se ejecutó en Windows PowerShell 5.1 (porque invocamos powershell.exe).

Decisión: Si crees que estás en PowerShell 7 pero no lo estás, los módulos y los valores TLS pueden diferir. Usa pwsh.exe explícitamente en perfiles que lo requieran.

Tarea 8: Confirma la disponibilidad de PowerShell 7 (y su ruta)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Command pwsh | Select-Object Source, Version"
Source                         Version
------                         -------
C:\Program Files\PowerShell\7\pwsh.exe 7.4.1

Qué significa: PowerShell 7 está instalado y es localizable.

Decisión: Apunta el commandline de tu perfil PowerShell 7 directamente a esta ruta para evitar rarezas del PATH.

Tarea 9: Lista distribuciones WSL instaladas (y elige un objetivo estable)

cr0x@server:~$ powershell.exe -NoProfile -Command "wsl.exe -l -v"
  NAME            STATE           VERSION
* Ubuntu          Running         2
  Debian          Stopped         2

Qué significa: WSL tiene Ubuntu y Debian. Ubuntu es la predeterminada (asterisco) y está ejecutándose.

Decisión: Si tienes múltiples distros, crea perfiles separados fijados con wsl.exe -d Ubuntu etc. No confíes en la distro por defecto.

Tarea 10: Mide el tiempo de arranque de un shell para detectar scripts de perfil lentos

cr0x@server:~$ powershell.exe -NoProfile -Command "Measure-Command { pwsh.exe -NoProfile -Command \"exit\" } | Select-Object TotalMilliseconds"
TotalMilliseconds
-----------------
142.8817

Qué significa: Iniciar PowerShell 7 sin cargar un perfil es rápido.

Decisión: Si -NoProfile es rápido pero el inicio normal es lento, tu script de perfil es el culpable. Arregla tus dotfiles, no Terminal.

Tarea 11: Identifica si tu perfil de PowerShell hace trabajo costoso

cr0x@server:~$ pwsh.exe -NoProfile -Command '$PROFILE; Test-Path $PROFILE; Get-Content $PROFILE -TotalCount 20'
C:\Users\cr0x\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
True
Import-Module posh-git
Import-Module oh-my-posh
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression

Qué significa: El perfil importa módulos e inicializa un tema de prompt. Eso puede ser lento, especialmente si los módulos están en una ubicación de red o el antivirus es agresivo.

Decisión: Cachea la inicialización del prompt, carga módulos perezosamente o crea un perfil “mínimo” para on-call.

Tarea 12: Comprueba si cargas rutas de home en red por accidente (tierra de latencia)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Item env:USERPROFILE, env:HOMEDRIVE, env:HOMEPATH, env:HOMESHARE | Format-Table -AutoSize"
Name        Value
----        -----
USERPROFILE C:\Users\cr0x
HOMEDRIVE   C:
HOMEPATH    \Users\cr0x
HOMESHARE

Qué significa: No hay un home en red configurado (en este ejemplo).

Decisión: Si HOMESHARE apunta a una ruta UNC, espera prompts lentos si tu perfil toca el directorio home al inicio.

Tarea 13: Verifica la disponibilidad de la fuente (detecta “puse una fuente que no está instalada”)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' | Select-String -Pattern 'Cascadia|Nerd|Caskaydia' -SimpleMatch"
Cascadia Mono (TrueType)    REG_SZ    CascadiaMono.ttf
Cascadia Code (TrueType)    REG_SZ    CascadiaCode.ttf

Qué significa: Las fuentes Cascadia existen. Tus ajustes que las referencian deberían funcionar.

Decisión: Si el nombre de fuente que elegiste no aparece, instálala o deja de referenciarla. Terminal no encontrará mágicamente una fuente que inventaste.

Tarea 14: Detecta conflictos de bindings buscando teclas duplicadas

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $raw = Get-Content $p -Raw; ($raw | Select-String -Pattern '\"keys\"' | Measure-Object).Count"
24

Qué significa: Hay 24 entradas de keybinding en el archivo (contando ocurrencias de la palabra "keys").

Decisión: Si has estado experimentando, probablemente tengas colisiones. Consolida. El mejor conjunto de bindings es el que puedes explicarle a un compañero.

Tarea 15: Valida que tu config SSH se esté usando (corrección de perfil)

cr0x@server:~$ wsl.exe -d Ubuntu -- bash -lc "grep -nE '^(Host|  HostName|  User|  IdentityFile)' ~/.ssh/config | head -n 20"
1:Host bastion-prod
2:  HostName bastion.prod.example
3:  User ops
4:  IdentityFile ~/.ssh/id_ed25519_ops

Qué significa: Tu config SSH define un host bastion con una clave específica.

Decisión: Crea un perfil de Terminal que ejecute ssh bastion-prod para que los operadores no escriban hostnames a las 3 a.m.

Guía de diagnóstico rápido: qué revisar primero/segundo/tercero

Esta es la triage rápida cuando Windows Terminal “se siente lento”, la entrada de texto tiene lag, las pestañas tardan mucho o el copiar/pegar se comporta de forma inconsistente. Buscas el cuello de botella, no sensaciones.

Primero: aísla si el problema es Terminal o el shell

1. Inicia un shell sin perfil (PowerShell: pwsh -NoProfile). Si es rápido, tus scripts de perfil son el problema.
2. Inicia una sesión tipo cmd mínima (o un perfil PowerShell mínimo). Si la UI del terminal sigue lenta, mira renderizado/fuentes y factores de GPU/Escritorio Remoto.
3. Prueba WSL con un comando mínimo (como wsl -d Ubuntu -- echo ok). Si eso es lento, está involucrado el arranque de WSL o la integración del sistema de archivos.

Segundo: revisa los tres principales sumideros de tiempo

1. Scripts de perfil que tocan la red: importaciones de módulos desde rutas UNC, git status en repos enormes, temas de prompt leyendo archivos a través de carpetas sincronizadas.
2. Antivirus en acción: especialmente en directorios de módulos o homes en OneDrive/rutas sincronizadas.
3. Comportamiento de fallback de fuentes/glifos: fuentes parcheadas o glifos faltantes pueden causar jank de renderizado y desalineación del cursor.

Tercero: identifica multiplicadores específicos del entorno

1. Sesiones de Escritorio Remoto: la aceleración gráfica e integración del portapapeles se comportan distinto; puedes ver lag de entrada que no existe localmente.
2. Buffer enorme y salida pesada: algunas CLIs emiten miles de líneas; el renderizado se vuelve cuello de botella. Reduce la salida o ajusta el scrollback.
3. Casos límite de ConPTY: apps de consola antiguas pueden comportarse mal; prueba ejecutarlas en la consola clásica como comprobación.

Si haces esto en orden, dejas de adivinar. También dejas de “optimizar” lo equivocado.

Errores comunes: síntoma → causa raíz → solución

1) “Mi prompt es lento; Terminal debe estar lento.”

Síntomas: Nuevas pestañas tardan segundos. El cursor aparece, pero no puedes escribir por un rato. Pico de CPU durante el inicio.

Causa raíz: Tu perfil de shell ejecuta trabajo costoso: git status en directorios grandes, importación de módulos, init de temas, comprobaciones de red, llamadas a CLIs de nube.

Solución: Crea dos perfiles: “mínimo” (on-call) con -NoProfile o un perfil delgado, y “completo” para dev diario. Carga módulos perezosamente y evita llamadas de red en la ruta del prompt.

2) “Mis íconos son cuadrados; Windows Terminal está roto.”

Síntomas: Separadores Powerline aparecen como tofu (□). Dibujo de cajas se ve mal. Alineación del prompt falla.

Causa raíz: Fuente sin glifos o fuentes de fallback inconsistentes. A veces configuraste un nombre de fuente que no está instalada.

Solución: Instala la fuente correcta y referencia su nombre exacto, o deja de usar prompts llenos de íconos. También ajusta lineHeight si hace falta para evitar solapamientos.

3) “Copiar/pegar es inconsistente y sigo pegando en prod.”

Síntomas: La selección a veces copia, a veces no. El clic derecho a veces pega. Ctrl+V se comporta distinto entre paneles/apps.

Causa raíz: Configuraciones mezcladas entre Terminal, shell y sesiones remotas; además de memoria muscular de otros terminales.

Solución: Decide una política y aplícala en la configuración: bindings y comportamiento de selección consistentes. Haz que el perfil de prod sea visualmente distinto para que tus ojos detecten el “panel equivocado”.

4) “Se duplicaron pestañas o los perfiles cambiaron tras una actualización.”

Síntomas: Aparecen nuevos perfiles por defecto; tus perfiles cuidadosamente nombrados están enterrados; el perfil predeterminado cambió.

Causa raíz: Perfiles auto-generados por shells instalados; tu defaultProfile no estaba fijado explícitamente; confiabas en el nombre en lugar del GUID.

Solución: Establece defaultProfile al GUID deseado. Cura profiles.list. Elimina u oculta perfiles auto-generados que no quieras mostrar.

5) “WSL arranca, pero las operaciones de archivos son dolorosamente lentas.”

Síntomas: Git status va a paso de tortuga. Instalaciones de Node tardan una eternidad. Todo en /mnt/c se siente lento.

Causa raíz: Estás haciendo cargas de trabajo tipo Linux en el montaje del sistema de archivos de Windows (/mnt/c), que es más lento que el filesystem ext4 de WSL para tareas con muchos metadatos.

Solución: Mantén los repos dentro del sistema de archivos de la distro WSL (por ejemplo, ~/src). Usa un perfil que inicie allí.

6) “Los atajos no funcionan en sesiones remotas.”

Síntomas: Los atajos de split no se activan; combinaciones de teclas son interceptadas.

Causa raíz: Mapas de teclas del cliente RDP, hotkeys a nivel OS o interceptaciones por aplicaciones.

Solución: Rebindea combos conflictivos en Terminal, y elige atajos que sobrevivan a tu tooling remoto. Prueba en la ruta real que usan los operadores.

Tres mini-historias corporativas (porque la realidad tiene giros)

Mini-historia 1: El incidente causado por una suposición errónea

Estaban migrando una canalización de build y release de Windows PowerShell legacy a PowerShell 7. Localmente todo parecía bien. En Windows Terminal, el ingeniero tenía un perfil “PowerShell” y asumió que eso significaba la nueva versión. El nombre coincidía con su modelo mental: PowerShell = moderno.

Durante un hotfix en producción, abrió una pestaña nueva y ejecutó un script que recuperaba dependencias usando valores TLS por defecto. Funcionó en su laptop cuando probó en pwsh. En la llamada del incidente falló en su pestaña porque en realidad era Windows PowerShell 5.1 con comportamientos y defaults diferentes. El mensaje de error no fue dramático; fue peor: fue ambiguo. La gente empezó a culpar al repositorio de artefactos.

“Arreglaron” reintentando y saltándose validaciones temporalmente de una forma que incomodó a seguridad. El hotfix se desplegó, pero el postmortem no fue agradable. La causa raíz no fue el repo. Fue el perfil de terminal equivocado. La pestaña parecía como cualquier otra.

La remediación fue aburrida y efectiva: nombres de perfil explícitos (“PowerShell 7” vs “Windows PowerShell”), commandlines fijados y un perfil por defecto establecido por GUID. También cambiaron el título de la pestaña para incluir PS7 o PS5. Después de eso, el modo de fallo dejó de existir. No se redujo. Se eliminó.

Mini-historia 2: La optimización que salió mal

Un equipo quería que sus prompts mostraran todo: rama git, estado dirty, contexto Kubernetes, cuenta de nube y el ID del ticket del incidente. Se veía impresionante en capturas y demos. También hacía un pequeño trabajo en cada render de prompt—significa cada comando, cada Enter, cada completado.

Para acelerarlo agregaron cache. Buena idea en teoría. La cache vivía en el directorio de perfil de usuario, que en máquinas corporativas estaba sincronizado y a veces redirigido. En condiciones normales iba bien. Con jitter en la VPN, las lecturas de cache se volvieron lentas y de pronto escribir se sintió con lag. La gente culpó al renderizado de Windows Terminal.

El verdadero problema apareció cuando un ingeniero intentó reducir salida en un incidente real abriendo paneles y haciendo tail de logs. El tema del prompt reevaluaba contexto en red constantemente; la cache thrasheaba. El terminal era responsivo; el shell no, y el operador peleaba contra su propio prompt.

Revirtieron a un prompt mínimo para perfiles de ops: solo rama git, sin búsquedas de red, sin contexto de nube. Dejaron el prompt elegante para perfiles de desarrollo. La optimización no era la villana; optimizar en el lugar equivocado sí lo fue. Segunda broma corta: El prompt más rápido es el que no intenta ganarse una bonificación de rendimiento.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización tenía una costumbre que parecía excesiva: mantenían un fragmento de settings.json versionado para ingenieros on-call. No era obligatorio, pero sí muy recomendado. El fragmento definía un conjunto pequeño de perfiles: “On-call PowerShell (mínimo)”, “WSL tooling”, “SSH bastion (prod)” y “SSH bastion (staging)”.

El perfil SSH de prod hacía algo poco glamuroso: ponía un título de pestaña muy visible, un esquema rojizo y un comando de inicio que imprimía un banner de advertencia corto. También forzaba una forma de cursor distinta. La gente bromeaba hasta la primera vez que evitó un error.

Durante una outage, un ingeniero tenía cuatro paneles: consulta de métricas, tail de logs, SSH a staging y SSH a prod. Casi pegó un comando de limpieza solo para staging en prod. Notó la forma del cursor y el título de la pestaña en el último segundo. Sin heroísmos, sin drama—solo una barandilla de seguridad haciendo su trabajo.

El postmortem fue casi anticlimático: “Casi hicimos algo malo, pero el perfil del terminal nos detuvo.” Eso es lo que quieres. La fiabilidad es mayormente ausencia de historias excitantes.

Listas de verificación / plan paso a paso

Plan A: Crea un conjunto de perfiles sensato en menos de una hora

1. Inventario tus shells: PowerShell 5.1, PowerShell 7, distros WSL, patrones de uso SSH.
2. Crea cuatro perfiles base:
   • PowerShell 7 (diario)
   • PowerShell 7 (mínimo / on-call)
   • WSL (tooling) iniciando en ~/src
   • SSH: bastion (prod) con visuales llamativos
3. Fija defaultProfile a la opción segura más común (a menudo PS7 minimal).
4. Elige una fuente y manténla. Si debes usar Nerd Fonts, hazlo intencionadamente y verifica glifos.
5. Define 6–10 atajos que realmente uses: nueva pestaña, cerrar pestaña (con confirm), dividir panel, enfocar panel, buscar, copiar, pegar.
6. Prueba el escenario de panel equivocado: abre perfiles prod/staging lado a lado y asegúrate de poder distinguirlos instantáneamente.
7. Valida JSON después de editar. No confíes en tu vista.

Plan B: Arregla lentitud sin romper tu flujo

1. Mide: cronometra pwsh -NoProfile vs inicio normal. Si hay una brecha, los scripts de perfil son culpables.
2. Minimiza: crea un perfil mínimo y úsalo cuando la latencia importe.
3. Elimina llamadas de red de prompts y arranques. Nada de comprobaciones de contexto en la nube, ni checks automáticos de actualización, ni git status en repos enormes por defecto.
4. Revisa fuentes y renderizado solo después de probar que el shell arranca rápido.
5. Estandariza: conserva una settings.json conocida y buena. La deriva es cómo “va lento en mi máquina” se vuelve deporte de equipo.

Plan C: Hazlo reproducible en el equipo

1. Define un fragmento baseline de settings.json (perfiles, esquemas, bindings).
2. Decide qué es personal: imagen de fondo, opacidad, temas experimentales—mantén eso fuera del baseline.
3. Documenta el contrato: qué significa el perfil “On-call”, qué carga y qué intencionalmente no carga.
4. Revisa cambios como código. Los keybindings y visuales de prod no deben ser “lo que sea.”

Una idea de fiabilidad que vale la pena recordar

Idea parafraseada (atribuida a John Allspaw): “El aprendizaje sin culpables funciona mejor cuando te concentras en cómo el contexto local de las personas hizo que sus acciones fueran razonables en ese momento.”

Los errores en el terminal suelen ser errores de contexto: panel equivocado, identidad equivocada, shell equivocado. Tu trabajo es hacer la acción correcta fácil y la acción equivocada obvia.

Preguntas frecuentes

1) ¿Debería editar la configuración en la UI o en settings.json?

Usa la UI para ajustes rápidos; usa JSON para cualquier cosa que quieras reproducir, revisar o revertir. Si te importa la consistencia, JSON es la fuente de la verdad.

2) ¿Por qué tengo múltiples perfiles de PowerShell?

Porque probablemente tienes Windows PowerShell (5.1) y PowerShell 7 instalados, y Terminal puede detectarlos automáticamente. Renómbralos claramente y fija commandlines para que siempre sepas qué estás ejecutando.

3) ¿Cuál es la mejor fuente?

La mejor fuente es la que puedes leer a las 3 a.m. y que renderiza tus símbolos correctamente. Empieza con Cascadia Mono. Cambia a una Nerd Font solo si tu prompt realmente necesita íconos.

4) Mi tema de prompt se ve genial pero es lento. ¿Qué hago?

Sepáralo en dos perfiles: un perfil ops mínimo y un perfil dev completo. Elimina búsquedas de red en el render del prompt y evita operaciones git costosas por defecto.

5) ¿Cómo evito pegar en el panel equivocado?

Haz que los entornos sean visualmente distintos (esquema, título, cursor). Asigna atajos para enfocar paneles que puedas pulsar sin pensar. Y mantén los perfiles de prod “ruidosos” a propósito.

6) ¿Por qué WSL es rápido en rutas Linux pero lento en /mnt/c?

Porque las cargas de trabajo con muchos metadatos (git, npm, builds de pequeños archivos) son más lentas en el montaje del sistema de archivos de Windows. Coloca repos en el filesystem de WSL y haz que tu perfil WSL inicie allí.

7) ¿Por qué cambió mi perfil predeterminado?

Actualizaciones e instalaciones de nuevos shells pueden agregar perfiles. Si no fijaste defaultProfile explícitamente por GUID, dejaste la decisión al azar. Fíjalo.

8) ¿Cómo mantengo atajos consistentes entre máquinas?

Mantén un settings.json base (o un fragmento) bajo control de versiones y aplícalo en las máquinas. Evita aleatoriedad por dispositivo en cosas que afectan navegación y seguridad.

9) ¿La aceleración por GPU causa problemas?

Normalmente ayuda. Cuando causa problemas, suele aparecer como glitches de render con ciertas fuentes o en sesiones remotas. Demuestra primero que el shell es rápido; luego prueba con una fuente más simple y menos efectos visuales.

Siguientes pasos que realmente harás

1. Crea un perfil on-call mínimo (PowerShell 7 con -NoProfile o un script de perfil ligero). Hazlo el predeterminado para trabajo en incidentes.
2. Renombra y fija tus perfiles para que nunca confundas PS5 vs PS7 o staging vs prod otra vez.
3. Elige una fuente, verifica que esté instalada y deja de perseguir dragones de glifos a menos que realmente los necesites.
4. Estandariza 6–10 atajos y practícalos hasta que sean automáticos. Bajo estrés, tus manos deben conocer la ruta.
5. Ejecuta la guía de diagnóstico rápido la próxima vez que Terminal “se sienta lento.” Mide primero. Luego arregla el cuello de botella real.

Si solo haces una cosa: haz que producción sea visualmente estridente y tu perfil on-call aburrido. Esa es profesionalidad disfrazada de estética.