DEV Community: Fede

Escribir Caracteres del Español con Teclado Inglés en Linux: Hackeando XKB sin Permisos de Root

Fede — Wed, 12 Aug 2026 17:41:25 +0000

Si te dedicas a la programación o infraestructura en Linux, sabrás que la distribución física de un teclado en inglés suele ser superior para escribir código o el manejo de la terminal. Caracteres clave como las comillas ", los paréntesis (), llaves {} y corchetes [] están mejor ubicados que en los teclados en español, sin mencionar lo incómodo que resulta en estos últimos encontrar la virgulilla ~ para hacer referencia al home.

Sin embargo, como hispanohablantes el tener el teclado con el layout en inglés nos impide escribir fácilmente caracteres acentuados o la letra eñe si tenemos que redactar correos, mantener conversaciones por chat, etc.

Frente a esta carencia, la solución tradicional suele ser activar variantes internacionales con teclas muertas (dead keys), pero trae complicaciones severas al programar. Por ejemplo, al intentar escribir un string ('api_key'), pulsar ' seguido de a inserta á. Entonces, para conseguir el símbolo suelto ', debes presionar ' y luego la barra espaciadora para "destrabar la tecla muerta".

¿Por que las llaman teclas muertas?
Es un mecanismo heredado de las máquinas de escribir mecánicas. En ellas, al pulsar la tecla del acento (como ´ o ¨), se imprimía la marca en el papel pero el carro no avanzaba ("muerta" porque no movía el papel). Al pulsar la siguiente vocal, esta se imprimía justo en la misma posición. Al llevar esta modalidad a los ordenadores, teclas como ', ", ` o ~ quedan bloqueadas a la espera de una segunda pulsación.

Durante un tiempo, mi solución fue configurar el teclado inglés más un mapa de teclado en español (a pesar de tener el teclado físico en inglés) y alternar constantemente entre ambos presionando Alt + Shift según estuviera en el editor de código o en aplicaciones de mensajería. Era un parche incómodo, propenso a errores y requería adivinar continuamente en qué modo estaba el teclado.

La búsqueda de una solución limpia me llevó a descubrir que en la distribución estadounidense existe una joya llamada us(altgr-intl) (EE. UU. AltGr Internacional). Con ella puedes escribir código normalmente (las comillas y backticks responden al instante) y si mantienes presionado AltGr + alguna vocal, obtienes acentos (á, é, í, ó, ú), y con AltGr + n, la ñ.

¿Por qué entonces escribir este post si ya he dado con la solución? Porque el portátil que tengo ahora tiene el teclado británico y esta distribución no tiene su equivalente nativo al us(altgr-intl) entonces toca crear uno que me otorgue esta solución.

Anatomía de XKB: Dónde Residen los Teclados en Linux

En la mayoría de las distribuciones de Linux, la gestión del teclado recae en el subsistema XKB y la librería libxkbcommon. Las definiciones de los mapas de teclado se encuentran centralizadas en el directorio del sistema /usr/share/X11/xkb/symbols/.

Dentro de este directorio, cada fichero representa una distribución base o Layout por país o idioma, como us (EE. UU.), gb (Reino Unido) o es (España), entre otros. A su vez, dentro de cada fichero se definen las distintas Variantes (subconfiguraciones como dvorak, mac o altgr-intl).

Editar directamente el archivo correspondiente a la distribución de nuestro teclado (en mi caso /usr/share/X11/xkb/symbols/gb) parecería lo obvio para obtener el comportamiento deseado. Sin embargo, esto requiere permisos de superusuario y podríamos perder nuestra configuración, ya que cualquier actualización del paquete xkeyboard-config sobrescribirá y borrará todos los cambios.

Por suerte, libxkbcommon implementa una jerarquía estricta de búsqueda para estos ficheros con un orden de prioridad:

1. Usuario (Prioridad Máxima):
   ~/.config/xkb/symbols/  (o $XDG_CONFIG_HOME/xkb/symbols/)
   ~/.xkb/symbols/         (Ruta legacy)

2. Sistema Global Custom (Prioridad Media):
   /etc/xkb/symbols/

3. Paquete del Sistema (Prioridad Baja):
   /usr/share/X11/xkb/symbols/

Esto significa que si colocamos dentro del directorio ~/.config/xkb/symbols/ un archivo llamado gb, el sistema lo evaluará como prioritario, cargándolo con preferencia absoluta sobre la versión del sistema.

Diseñando la Variante `altgr-intl` en XKB para el layout de teclado británico

La estructura de un fichero de definición XKB se organiza en bloques xkb_symbols y dentro podemos mapear hasta 4 niveles de caracteres por tecla de la siguiente manera:

key <Cod_tecla> { [ Nivel 1, Nivel 2, Nivel 3, Nivel 4 ] };

Donde:

Nivel 1: Presionar la tecla sin más.
Nivel 2: Tecla + Shift.
Nivel 3: Tecla + AltGr (aquí es donde modificaremos su comportamiento).
Nivel 4: Tecla + AltGr + Shift (aquí también).

💡 ¿Cómo nombra XKB las teclas físicas?
XKB no identifica las teclas por la letra impresa en el teclado, sino por su posición (de abajo a arriba por filas AA a AE, y de izquierda a derecha por columnas 01 a XX):

Fila AE (Números): <AE01> = 1, <AE02> = 2...

Fila AD (Letras superiores): <AD01> = Q, <AD02> = W, <AD03> = E...

Fila AC (Home Row): <AC01> = A, ..., <AC04> = F...

Fila AB (Letras inferiores): <AB01> = Z, ..., <AB06> = N...

Fila AA (Ctrl, Alt, Espacio...): <AA01> = Ctrl Izquierdo, <AA08> = Espacio... Aunque para estas teclas XKB tiene alias como y respectivamente.

Para implementar nuestra variante manteniendo la herencia de gb(basic), tenemos dos opciones:

Copiar el archivo base del sistema /usr/share/X11/xkb/symbols/gb a nuestra ruta local ~/.config/xkb/symbols/gb y añadir nuestro bloque altgr-intl al final. De esta manera, la directiva include "gb(basic)" encontrará la sección basic definida dentro del mismo archivo local.
Crear un archivo con nombre personalizado y guardar nuestro bloque allí como ~/.config/xkb/symbols/gb_custom. Al llamarse distinto del archivo del sistema, XKB buscará la sección basic directamente al fichero oficial /usr/share/X11/xkb/symbols/gb.

La estructura de la nueva variante queda así:

partial alphanumeric_keys
xkb_symbols "altgr-intl" {
    // 1. Heredar la base del teclado británico estándar
    include "gb(basic)"

    name[Group1]= "English (UK, AltGr international)";

    // 2. Mapear acentos y la letra ñ al Nivel 3 (AltGr) y Nivel 4 (AltGr+Shift)
    key <AD03> { [ e, E, eacute, Eacute ] };
    key <AD07> { [ u, U, uacute, Uacute ] };
    key <AD08> { [ i, I, iacute, Iacute ] };
    key <AD09> { [ o, O, oacute, Oacute ] };
    key <AC01> { [ a, A, aacute, Aacute ] };

    key <AB06> { [ n, N, ntilde, Ntilde ] };

    // 3. Habilitar la tecla Alt Derecho (Right Alt) como conmutador de Nivel 3
    include "level3(ralt_switch)"
};

Desglose técnico del código:

partial alphanumeric_keys: Le indica a XKB que este bloque no define un teclado completo desde cero, sino una modificación parcial centrada en la sección alfanumérica del teclado.
include "gb(basic)": Carga todo el mapeo físico estándar impreso en los teclados británicos para que no tengamos que declarar todas las teclas.
key <AD03>: Accede a la 3ª tecla de la fila superior (la E). Al definir [ e, E, eacute, Eacute ], asignamos la é minúscula al pulsar AltGr + e, y la É mayúscula al pulsar AltGr + Shift + e, dejando su comportamiento normal para los dos primeros niveles.
include "level3(ralt_switch)": Indica a XKB que la tecla Alt Derecho (Right Alt) actuará como selector del Nivel 3.

Activación en el Entorno

Una vez creado el archivo en ~/.config/xkb/symbols/gb (o gb_custom), el último paso es indicarle al compositor que cargue esta nueva variante.

En mi caso, utilizo Hyprland como gestor de ventanas, por lo que basta con añadir estas líneas en mi archivo de configuración:

En la configuración de Hyprland (`~/.config/hypr/hyprland.conf`):

input {
    kb_layout = gb          # O "gb_custom" si usaste un archivo independiente
    kb_variant = altgr-intl
}

Al recargar Hyprland, mantengo el 100% de los símbolos impresos en mi teclado británico y gano acceso directo e instantáneo a tildes (á, é, í, ó, ú) y a la ñ simplemente combinando las teclas con AltGr.

Llévalo al Siguiente Nivel: Hacks de Teclado Personalizados

Entender la estructura de xkb_symbols te abre la puerta a adaptar cualquier teclado a tus necesidades específicas.
Ten en cuenta que no es obligatorio definir siempre los 4 niveles: si solo necesitas una combinación con AltGr, basta con declarar 3 elementos dentro de los corchetes [ ].

Te dejo 4 ideas prácticas como ejemplos útiles:

1. Arreglar la Virgulilla (`~`) en el Teclado Español

En el teclado de España (es), escribir la virgulilla ~ exige presionar AltGr + 4 seguido de la barra espaciadora por actuar como tecla muerta. Puedes hacer que se imprima directamente con AltGr + ñ declarando solo 3 niveles:

key <AC10> { [ ñ, Ñ, asciitilde ] };

2. Descongelar la Comilla Invertida / Backtick (`) en el Teclado Español

Como programador, el backtick ` es un operador crítico. En distribuciones en español actúa como tecla muerta para el acento grave (como en francés à), obligándote a presionar la tecla y luego espacio. Puedes redefinirla para que imprima el backtick directo en Nivel 3:

// Imprime ` de forma directa en Nivel 1, manteniendo Shift + tecla = ^ y AltGr + tecla = [
key <AD11> { [ grave, dead_circumflex, bracketleft ] };

(O si también deseas descongelar el circunflejo ^ para que no sea tecla muerta)

key <AD11> { [ grave, asciicircum, bracketleft ] };

3. Símbolos de Monedas e Iconos Financieros (`€`, `£`, `$`, `₿`, `💰`)

Si trabajas con plataformas internacionales o finanzas, puedes asignar símbolos monetarios en el Nivel 3 y emojis gráficos relacionados en el Nivel 4:

// AltGr + e -> € (Euro) | AltGr + Shift + e -> 💶 (Billete de Euro)
key <AD03> { [ e, E, EuroSign, U1F4B6 ] };

// AltGr + b -> ₿ (Bitcoin) | AltGr + Shift + b -> 💰 (Bolsa de Dinero)
key <AB05> { [ b, B, U20BF, U1F4B0 ] };

4. Emojis y Símbolos de Redacción Rápida

Si redactas documentación con frecuencia y quieres evitar abrir un picker de emojis o buscar símbolos especiales:

// AltGr + s -> 🚀 (U1F680 Cohete) | AltGr + Shift + s -> 💡 (U1F4A1 Bombilla)
key <AC02> { [ s, S, U1F680, U1F4A1 ] };

// AltGr + m -> — (Raya / Guion largo de diálogo U2014)
key <AB07> { [ m, M, U2014 ] };

¿Se te ocurre alguna otra configuración útil? Compártela!

De comandos manuales a scripts dinámicos: Cómo simplifiqué la clonación de Windows en WinPE con DISM

Fede — Fri, 10 Jul 2026 22:21:34 +0000

¿Alguna vez te has encontrado en esa situación donde hay una herramienta que te resuelve un problema pero en tu empresa no está permitida?
Ya sea porque usan otra alternativa, por políticas de seguridad o simplemente por decisiones corporativas, te ves obligado a adaptarte.

Aunque al principio esto puede parecer frustrante (sobre todo cuando crees que tu herramienta habitual te haría el trabajo más rápido y cómodo), en realidad es una oportunidad de oro. Te obliga a aprender cómo funciona el nuevo entorno y da la excusa perfecta para programar tus propios scripts desde cero para automatizar y simplificar el trabajo diario.

En mi caso, me enfrenté a la clásica tarea de infraestructura: clonar imágenes de discos y realizar despliegues a partir de preinstalaciones de Windows.
En este entorno, la herramienta permitida era DISM, que viene de forma nativa en la suite de Windows y no requiere instalación extra.

Si quieres ir directo al grano, puedes consultar y descargar los scripts completos en el repositorio del proyecto en GitHub.

Aquí es donde empieza esta historia.

Despliegue Unificado: Menú Dinámico y Formateo en un solo Script

La primera vez que me tocó hacer un deploy en el trabajo, el punto de partida fue un archivo de texto con una línea de comando extensa que los técnicos copiábamos y pegábamos directamente en la consola de WinPE. Además, debíamos modificar manualmente el nombre de la imagen .wim que queríamos aplicar.
Para preparar el disco antes del despliegue, también contábamos con un bloque de instrucciones de diskpart (limpiar volumen, crear tabla GPT, definir particiones EFI y Windows), que estaba almacenado en un archivo de texto independiente.

Tener comandos dispersos y archivos de configuración sueltos por el disco de herramientas me generaba desconfianza.
Si un archivo se borra u otro se desactualiza, el proceso se interrumpe y falla resultando en una pérdida de tiempo en tareas que suelen demorar bastante.

Pensé: "Esto tiene que poder hacerse mejor".

La solución fue crear deploy.cmd para concentrar todo el despliegue en un único script autoportante que realiza tres tareas clave de forma secuencial:

1. Escaneo dinámico y menú interactivo

Para evitar errores de tipeo al introducir el nombre de la imagen .wim, el script barre el directorio donde se almacenan y las lista en un menú.
La decición de hacerlo así fue para que sea escalable y dinámico permitiendo agregar imágenes al directorio sin necesidad de modificar el script.

:: Escaneo dinámico de imágenes
set COUNT=0
for %%A in ("%IMG_DIR%\*.wim") do (
    set /a COUNT+=1
    set "WIM[!COUNT!]=%%~fA"
    set "WIM_NAME[!COUNT!]=%%~nA"
)

:: ... generación del menú interactivo ...

Este simple bucle for detecta los archivos de un directorio y almacena las rutas en "arrays" simulados de Batch, generando opciones numeradas para que solo deba seleccionar una y el script se encargará del resto.

Nota de sintaxis: El uso de signos de exclamación (!) en lugar del porcentaje (%) tradicional de Batch se debe a la necesidad de habilitar la expansión retardada (setlocal enabledelayedexpansion). Sin esto, Batch evaluaría las variables del menú al cargar el bucle en memoria y no en tiempo de ejecución, lo que rompería la lógica del índice dinámico.

2. Integración de DiskPart al vuelo

En lugar de depender de un archivo de texto externo para particionar el disco, el propio script genera las instrucciones de diskpart en el directorio temporal y las ejecuta en segundo plano:

set "TEMP_SCRIPT=%temp%\dp_script.txt"

(
  echo select disk %TARGET_DISK%
  echo clean
  echo convert gpt
  echo create partition efi size=200
  echo format quick fs=fat32 label="EFI"
  echo assign letter=S
  :: ... creación de particiones MSR y Windows ...
) > "%TEMP_SCRIPT%"

diskpart /s "%TEMP_SCRIPT%" >> "%LOG_FILE%" 2>&1
del "%TEMP_SCRIPT%"

Lo ejecutamos silenciosamente con diskpart /s y registramos su salida en un archivo de log (%LOG_FILE%) para diagnosticar posibles fallos.

3. Configuración automática de arranque UEFI

Una vez que DISM vuelca la imagen seleccionada, el script ejecuta el paso final para que el sistema sea arrancable de forma automática sin intervención manual:

bcdboot Z:\Windows /s S: /f UEFI >> "%LOG_FILE%" 2>&1

Este comando escribe los archivos de arranque en la partición EFI (S:) apuntando a la instalación de Windows que acabamos de aplicar en la partición primaria (Z:).

Al concentrar todo en un único archivo de script, logramos un proceso autocontenido: el mismo archivo prepara el hardware, automatiza la selección de la imagen y configura el arranque UEFI.

El Siguiente Desafío: La Migración Masiva y el Script de Captura

Tener un script de despliegue sólido fue un gran avance, pero el verdadero desafío apareció con una actualización masiva de discos HDD a SSD.

Normalmente, un proceso de captura se hace una sola vez: se prepara un sistema de referencia, se captura la imagen base y se despliega tantas veces como haga falta. Sin embargo, en una migración de hardware uno a uno no se puede hacer eso. Cada equipo debe conservar intactos los datos, perfiles y controladores específicos de su usuario. Esto significaba realizar una captura y un despliegue individual por cada ordenador del parque.

Al multiplicar el proceso por el número de máquinas a actualizar, cualquier fricción manual se vuelve crítica.
Fue en este escenario donde nació capture.cmd y donde me topé con una limitación de DISM al procesar perfiles: el tratamiento de los archivos de OneDrive almacenados en la nube.

DISM no procesa correctamente los punteros o enlaces de archivos que solo residen en la nube de OneDrive. Al capturar la imagen, el comando finalizaba sin indicar ningún error. Sin embargo, al desplegar esa misma imagen en un nuevo ordenador, el proceso fallaba a mitad de camino y se suspendía.

Esto me obligaba a montar la imagen capturada en otro ordenador para limpiarla a mano, o a repetir la captura borrando previamente los directorios de OneDrive de los perfiles afectados.

La solución que encontré era usar el parámetro /ConfigFile de DISM para excluir los ficheros dentro de las carpetas de OneDrive pero los comodines de exclusión estándar de DISM resultaron ser muy erráticos. Por ejemplo, una regla genérica como Users/*/OneDrive* no solo excluía los archivos sincronizados en la nube, sino que también coincidía con ejecutables internos como Users/usuario/AppData/Microsoft/OneDrive/OneDrive.exe, provocando fallos en el perfil al iniciar sesión tras el despliegue.

Para resolverlo de forma limpia, la solución fue crear de manera dinámica el archivo de configuración exclude.ini personalizado antes de iniciar la captura.

El código en acción: Generación de exclusiones al vuelo

Este es el bloque que resuelve el problema en capture.cmd:

(
echo [ExclusionList]
:: ... exclusiones estándar del sistema ...
for /d %%U in ("%WINDOWS_PARTITION%\Users\*") do (
    set "USER_NAME=%%~nxU"
    if /I not "!USER_NAME!"=="All Users" (
        for /d %%O in ("%%U\OneDrive*") do (
            echo \Users\!USER_NAME!\%%~nxO\*
        )
    )
)
) > "%TEMP%\exclude.ini"

¿Cómo funciona este filtro dinámico?

Exclusiones del sistema estándar: Primero escribimos en el archivo temporal las exclusiones clásicas de Windows (archivos de paginación, papelera, etc.) que no deben incluirse en una clonación limpia.
Iteración de perfiles de usuario: Mediante for /d %%U barremos el directorio Users. Guardamos el nombre de cada carpeta en USER_NAME.
Filtro de cuentas y búsqueda de OneDrive: Omitimos cuentas del sistema como "All Users". Luego, buscamos directorios que comiencen con OneDrive dentro del perfil de cada usuario (%%U\OneDrive*).
Rutas absolutas sin comodines destructivos: Si se encuentra una carpeta de OneDrive para ese usuario específico, escribimos su ruta absoluta exacta (por ejemplo, \Users\usuario\OneDrive - Empresa\*) en la sección de exclusiones.

⚠️ El peligro oculto de /ConfigFile en DISM

Un comportamiento crítico de DISM es que, al pasarle un archivo /ConfigFile personalizado, se desactivan por completo sus exclusiones nativas por defecto. Si no se declaran de nuevo a mano, archivos masivos de sistema como pagefile.sys, hiberfil.sys o carpetas de reciclaje se incluirán en la captura. Por ello, el script escribe primero estas exclusiones estándar al inicio del archivo temporal.

Una vez generado el archivo en %TEMP%\exclude.ini, llamamos a DISM pasándole este archivo como parámetro:

Dism /Capture-Image /ImageFile:"%DESTINATION%\%IMAGE_NAME%" /CaptureDir:%WINDOWS_PARTITION%\ /Name:"My Windows partition" /ConfigFile:"%TEMP%\exclude.ini" /CheckIntegrity

Al terminar, el script elimina el archivo .ini temporal. Esto garantizó capturas exitosas sin intervención manual en los perfiles de usuario y sin falsos positivos en las exclusiones.

Conclusiones y Trade-offs

A veces, las soluciones de infraestructura más robustas no requieren suites de software de terceros complejas ni dependencias pesadas. La combinación de scripts de consola de Batch y herramientas nativas como DISM y DiskPart nos permitió construir un flujo de clonación confiable, dinámico y robusto.

Como en cualquier decisión de diseño técnico, hubo compromisos:

Ventajas: Es universal, ligero y se ejecuta en cualquier entorno WinPE sin requerir red ni dependencias. Aunque PowerShell suele ser la primera opción para automatizar en Windows, muchas imágenes de arranque WinPE minimalistas omiten el soporte de PowerShell para ahorrar tamaño. Batch garantiza que el script funcione de forma nativa en cualquier consola de recuperación por básica que sea.
Trade-offs: La sintaxis de Batch es rígida, carece de un manejo de errores sofisticado y la manipulación de variables en bucles requiere habilitar la expansión retardada (setlocal ENABLEDELAYEDEXPANSION), lo cual añade cierta complejidad al código.

Esta automatización transformó un proceso manual propenso a fallos tipográficos en una tarea de selección de opciones en un menú, asegurando que cada clonación e instalación se realizara sobre un estado limpio y predecible.

El código fuente completo de los scripts y las instrucciones de uso están disponibles en el repositorio del proyecto en GitHub. ¡Las sugerencias, reportes de fallos y contribuciones son más que bienvenidos!