Cuando ves un archivo en el sistema de ficheros, la extensión es solo una sugerencia —una convención que nadie está obligado a respetar. El kernel no la usa para nada; lo que determina cómo tratar un fichero son sus primeros bytes. La herramienta file lee esos magic bytes (la firma binaria que está incrustada al principio de casi cualquier formato conocido) y los compara contra una base de datos en /usr/share/misc/magic.mgc para decirte qué contiene realmente el fichero. Puedes renombrar un PNG a .txt y file seguirá diciéndote que es PNG.
Esto importa en producción más de lo que parece: un script de despliegue que asume tipos por extensión fallará en silencio si alguien subió un archivo mal nombrado. Y cuando estás depurando datos binarios —cabeceras de protocolos, archivos de configuración compilados, volcados de memoria— necesitas ver los bytes directamente, no la interpretación de tu editor de texto.
Ahí entra xxd, que vuelca cualquier fichero en hexadecimal con la representación ASCII al lado. Junto a file, forman el mínimo indispensable para diagnosticar qué es realmente un fichero y qué contiene byte a byte.
El error clásico que une estas herramientas es hacer cat sobre un binario. El problema no es que “se vea feo” —es que los bytes de control embebidos en cualquier binario (ESC sequences, bytes nulos, códigos de cambio de modo) se interpretan directamente por el emulador de terminal, que puede cambiar su modo de entrada, deshabilitar el eco, o entrar en estados que hacen que todo lo que escribas no se vea y no funcione. Si ejecutas cat foto.jpg y la terminal deja de responder o empieza a mostrar basura, no cierres la ventana: escribe reset a ciegas y pulsa Enter. El comando reset reinicializa el terminal a su estado por defecto mediante tput reset internamente, y funciona aunque no veas lo que escribes porque el kernel sigue recibiendo tu entrada aunque el echo esté roto.
# Tenemos tres ficheros sospechosos para investigar ls -lh datos/ # Paso 1: identificar qué son realmente, sin fiarse de los nombres file datos/informe.pdf datos/imagen.png datos/config.bin # Ejemplo de salida típica: # datos/informe.pdf: PDF document, version 1.6 # datos/imagen.png: PNG image data, 1920 x 1080, 8-bit/color RGB, non-interlaced # datos/config.bin: ELF 64-bit LSB executable, x86-64, ... (¡no es config!) # Paso 2: verificar manualmente los magic bytes de config.bin con xxd # Las primeras 4 líneas (32 bytes) suelen contener la firma del formato xxd datos/config.bin | head -4 # Salida esperada para un ELF: # 00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ # ^^^^^^^^ ^^^^ los 4 primeros bytes: 7f 45 4c 46 = .ELF # Paso 3: inspeccionar un fichero de texto para confirmar codificación file datos/script.sh # datos/script.sh: Python script, UTF-8 Unicode text executable # (file detecta el shebang y la codificación, no solo la extensión) # Paso 4: buscar un patrón concreto dentro de un binario # Por ejemplo, verificar que un fichero SQLite tiene la firma correcta xxd datos/base.db | head -2 # 00000000: 5351 4c69 7465 2066 6f72 6d61 7420 3300 SQLite format 3. # La firma ASCII "SQLite format 3" empieza justo en el offset 0x00 # Paso 5: si ya hiciste cat sobre un binario y la terminal está rota, # escribe esto a ciegas (aunque no veas el cursor ni los caracteres): reset # Enter — el terminal vuelve al estado normal # Alternativa si reset no está en el PATH por algún motivo raro: tput reset # Mismo efecto; tput usa la base de datos terminfo para tu $TERM actual # Paso 6: para ficheros grandes, xxd con rango de bytes # Ver 64 bytes a partir del offset 512 (cabecera de segunda partición, por ejemplo) xxd -s 512 -l 64 datos/config.bin # hexdump -C es equivalente a xxd en formato, pero viene en util-linux # xxd viene en el paquete vim-common — en Debian siempre está instalado # si tienes vim instalado; si no: apt install xxd (paquete independiente desde Bookworm) hexdump -C datos/config.bin | head -4
Lo que hace file internamente es leer un número pequeño de bytes del inicio del fichero (y a veces del final, como hacen los archivos ZIP que almacenan su directorio central al final) y aplicar las reglas de /etc/magic más las compiladas en /usr/share/misc/magic.mgc. Con la opción -i obtienes el MIME type en lugar de la descripción en texto —útil si necesitas procesar la salida con un script.
En el bloque de arriba, xxd datos/config.bin | head -4 muestra la estructura fundamental de la salida: columna izquierda con el offset en hexadecimal, 16 bytes por línea en grupos de 2 bytes, y la representación ASCII a la derecha donde los bytes no imprimibles aparecen como puntos. Esa alineación es lo que te permite saltar mentalmente entre la posición exacta en el fichero y su valor. Cuando buscas 7f 45 4c 46 en los primeros cuatro bytes y ves .ELF, estás confirmando que ese fichero es un ejecutable ELF —el magic number que el kernel comprueba antes de intentar ejecutar cualquier binario.
El flag -s 512 -l 64 de la línea de inspección por rango hace saltar xxd directamente al byte 512 sin leer lo anterior —relevante cuando trabajas con ficheros de varios gigabytes y no quieres esperar un head sobre un volcado completo.
Sobre reset a ciegas: funciona porque el problema casi siempre es que los bytes de control han cambiado los flags del terminal en la capa termios del kernel —el eco está desactivado, o el terminal está en modo raw, o la codificación está confundida. reset envía la secuencia de inicialización completa definida en la base de datos terminfo para tu $TERM actual, restablece todos los flags de stty a sus valores por defecto y limpia el estado del emulador. Lo que escribe en el buffer de la terminal llega al kernel igualmente aunque no lo veas; el eco roto no afecta a la recepción de caracteres.
N° 31