Módulo 2: Trabajar con archivos y texto

4. Leer archivos: cat, less, head y tail

Descripción

Al terminar esta lección vas a poder elegir, sin dudar, qué herramienta usar para leer cualquier archivo de texto —desde un archivo de configuración de diez líneas hasta un log de producción de un millón— y vas a poder seguir ese log mientras crece, en tiempo real, sin refrescar nada a mano.

Esto no es un ejercicio de trivia de terminal. Revisar logs es probablemente la tarea más repetida de cualquier trabajo con backend, infraestructura o datos: un servicio falla y el primer movimiento de alguien con experiencia es abrir una terminal y mirar el log, no un dashboard. Elegir la herramienta correcta según el tamaño del archivo —y no dejar tu propia terminal inservible por usar la incorrecta— es la diferencia entre diagnosticar un incidente en treinta segundos o pelear diez minutos contra tu propia pantalla.

Conexión con el módulo: ya sabes crear estructura con mkdir y touch, y mover, copiar y borrar aplicando un criterio de seguridad explícito. Te faltaba la pieza que conecta con lo que sigue: mirar el contenido real de esos archivos. Sin esto, find —la próxima lección— solo te va a decir dónde está un archivo, nunca qué hay adentro.

El criterio real: el tamaño del archivo decide

Cuando alguien te manda un mensaje de tres líneas, lo lees entero de un vistazo. Cuando te entregan un legajo de trescientas páginas, no lo lees de la página uno a la última sin parar: revisas el índice, saltas al capítulo que te interesa, y si necesitas encontrar una palabra específica no pasas hoja por hoja, la buscas. La terminal tiene una herramienta para cada uno de esos gestos, y elegir mal no es un error de estilo: con un archivo grande puede dejar tu terminal atascada varios segundos imprimiendo texto que jamás vas a leer, o hacerte perder de vista justo el dato que buscabas entre miles de líneas que pasaron volando.

Antes de decidir, mides. wc (word count) con la bandera -l cuenta líneas sin mostrarte ni una:

wc -l archivo.txt

Con ese número en la mano, el criterio es simple:

  • Pocas líneas (todo cabe en una pantalla): cat lo vuelca completo y listo.
  • Muchas líneas: less lo abre como un visor real, cargando de a partes, con navegación y búsqueda.
  • Solo te interesa un extremo (el principio o el final, sin importar el tamaño): head o tail.

Ejemplo trabajado

Empieza por un archivo corto. Créalo con contenido real usando echo y el operador >> (agrega una línea al final de un archivo sin borrar lo que ya tenía; es un operador de redirección que vas a estudiar a fondo en el módulo de pipes y redirección — aquí lo usamos solo para tener un archivo de ejemplo):

echo "Review Friday's deploy" >> notes.txt
echo "Request access to the staging database" >> notes.txt
echo "Confirm meeting with the data team" >> notes.txt

Mide antes de abrir:

wc -l notes.txt

Qué esperar:

3 notes.txt

Tres líneas caben en cualquier pantalla, así que cat (de concatenate: unir y volcar) es exactamente la herramienta correcta:

cat notes.txt

Qué esperar:

Review Friday's deploy
Request access to the staging database
Confirm meeting with the data team

Ahora el otro extremo. La mayoría de los sistemas Unix (macOS y muchas distribuciones de Linux) traen un archivo con una lista de palabras en /usr/share/dict/words, pensado originalmente para el corrector ortográfico del sistema. Es perfecto como archivo "grande" real, sin que tengas que fabricarlo. Mide primero:

wc -l /usr/share/dict/words

Qué esperar: un número de cientos de miles (el valor exacto varía según tu sistema operativo y su versión; no es el número lo que importa, sino el orden de magnitud). Si tu máquina no tiene ese archivo, reemplázalo en los ejemplos que siguen por cualquier archivo de texto largo que tengas a mano: un log real, un CSV grande, o tu historial de shell (~/.zsh_history o ~/.bash_history).

Si corrieras cat /usr/share/dict/words ahora, cientos de miles de líneas desfilarían por tu pantalla en un segundo, y terminarías viendo solo la última pantalla, sin forma de volver al principio salvo correr el comando de nuevo. Ese es el mal uso típico de cat: usarlo como si fuera un visor cuando el archivo no es corto. Con un archivo de verdad grande —un log de un millón de líneas, por ejemplo— la terminal encima puede quedarse "pensando" varios segundos, imprimiendo texto que no vas a leer.

Para esto existe less: un visor de verdad, que carga el archivo de a partes en vez de volcarlo entero.

less /usr/share/dict/words

Dentro de less, la navegación es con teclas, no con el mouse:

TeclaAcción
Espacio o favanza una pantalla
bretrocede una pantalla
gsalta a la primera línea
Gsalta a la última línea
/patrón + Enterbusca hacia adelante
?patrón + Enterbusca hacia atrás
nrepite la búsqueda en la misma dirección
Nrepite la búsqueda en dirección contraria
qsale del visor

Prueba una búsqueda real: dentro de less, escribe /terminal y presiona Enter. Qué esperar: el cursor salta a la primera línea que contiene esa palabra y la resalta; si presionas n, salta a la siguiente coincidencia (puede haber varias entradas relacionadas, como palabras compuestas). Presiona q cuando termines: sales del visor y vuelves exactamente a tu prompt de terminal, sin haber cerrado la ventana ni perdido tu sesión.

Si quieres ver los números de línea desde que abres el archivo (útil para referenciar una línea exacta más adelante), arráncalo con -N:

less -N /usr/share/dict/words

Qué esperar: cada línea con su número al margen izquierdo, algo así al principio del archivo:

     1  A
     2  a
     3  aa
     4  aal
     5  aalii

Por último, si solo te interesa un extremo y no necesitas navegar nada en el medio, head y tail te lo dan sin abrir el archivo completo:

head -n 5 /usr/share/dict/words
tail -n 5 /usr/share/dict/words

Qué esperar: head -n 5 muestra las primeras cinco líneas (por el orden alfabético del archivo, entradas cortas como las de la tabla de arriba); tail -n 5 muestra las últimas cinco (palabras que empiezan con las últimas letras del alfabeto). Sin la bandera -n, ambos comandos muestran 10 líneas por defecto — ese valor no depende del tamaño del archivo, es un valor fijo de la herramienta.

Siguiendo un archivo en vivo: tail -f

Todo lo anterior asume un archivo quieto, que ya terminó de escribirse. Pero un log de un servicio corriendo se sigue escribiendo mientras tú lo miras. Para eso existe una bandera de tail que vas a usar el resto de tu carrera: -f, de follow.

Abre dos pestañas o ventanas de terminal apuntando a la misma carpeta. En la primera (llamémosla A):

touch app.log
tail -f app.log

La terminal no te devuelve el prompt: se queda ahí, esperando. Eso es exactamente lo que hace -f — en vez de mostrar las últimas líneas y salir como haría un tail -n normal, se queda observando el archivo y te muestra cada línea nueva apenas se escribe, sin que vuelvas a correr nada.

En la segunda pestaña (B), en la misma carpeta, simula una línea nueva de log:

echo "2026-07-21 10:03:12 INFO server started" >> app.log

Vuelve a la pestaña A. Qué esperar: sin que hayas tocado nada ahí, apareció sola la línea nueva:

2026-07-21 10:03:12 INFO server started

Repite en la pestaña B con otra línea:

echo "2026-07-21 10:03:45 ERROR connection refused" >> app.log

Y en la pestaña A esa línea también aparece al instante, sin que hicieras nada. Para detener el seguimiento, Ctrl+C — te devuelve el prompt de la pestaña A.

Esto es, literalmente, cómo vas a diagnosticar la mayoría de los incidentes en producción: dejas tail -f corriendo sobre el log del servicio mientras reproduces el bug o esperas a que ocurra, y ves los errores aparecer en el momento exacto en que pasan.

Qué pasa si abres un binario (y cómo recuperar la terminal)

No todos los archivos son texto. Un binario compilado, una imagen, un .zip, contienen bytes que no son caracteres imprimibles. Si le corres cat a uno de estos por error:

cat /bin/ls

Qué esperar: una pantalla llena de símbolos extraños y, en el peor caso, tu terminal cambia de comportamiento —el texto que escribas después no se ve, o los colores salen raros—. Esto pasa porque los bytes del binario incluyen secuencias de escape (códigos de control que los programas usan, por ejemplo, para cambiar el color del texto en la terminal), y la terminal las interpreta al pie de la letra, quedando con su configuración alterada.

La terminal no se rompió de verdad, y la solución no es cerrar la ventana: es el comando reset.

reset

Escríbelo aunque no veas lo que tecleas —a veces la terminal queda tan confundida que ni el eco del teclado funciona— y presiona Enter. reset reinicializa la terminal a su configuración por defecto: recupera el eco de teclado, el modo de línea normal y los caracteres especiales. Vas a perder el historial de scroll hacia atrás, pero la terminal vuelve a ser usable.

Errores comunes

Pensar que cat es un visor. cat fue diseñado para concatenar y volcar archivos a la salida estándar lo más rápido posible, no para paginar ni navegar — ese malentendido es el que lleva a correrlo sobre un archivo de un millón de líneas y quedarse con la terminal atascada. Se detecta cuando después de un cat solo puedes ver la última pantalla y no hay forma de volver atrás sin correr el comando de nuevo. Se corrige midiendo primero con wc -l y usando less (o head/tail) en cuanto el archivo no cabe entero en una pantalla.

Creer que tail -f se colgó. Si corres tail -f y el prompt no vuelve, es tentador pensar que el comando falló o que la terminal se congeló. En realidad ese es su comportamiento correcto: está esperando escrituras nuevas en el archivo, indefinidamente, hasta que tú decidas parar. Se detecta porque Ctrl+C sí responde de inmediato (si la terminal estuviera realmente trabada, tampoco respondería a eso). Se corrige con Ctrl+C para detener el seguimiento y recuperar el prompt.

Asumir que las 10 líneas por defecto son todo el archivo. Correr head o tail sin -n y dar por hecho que el archivo termina ahí es un error común cuando alguien no sabe que 10 es un valor fijo de la herramienta, no un reflejo del tamaño real del archivo. Se detecta comparando contra wc -l: si head (sin bandera) muestra 10 líneas pero wc -l dice 50,000, hay 49,990 líneas que no viste. Se corrige usando -n con el número que necesites, después de medir con wc -l.

Ejercicios

Ejercicio 1 — Mide y decide. Tienes un archivo llamado sales-data.csv en tu carpeta actual y no sabes cuántas líneas tiene. ¿Qué comando corres para averiguarlo antes de decidir cómo abrirlo? Si el resultado es 40, ¿qué herramienta usarías para leerlo completo? Si el resultado es 800,000, ¿cuál usarías, y por qué no cat?

Ver solución
wc -l sales-data.csv

Con 40 líneas: cat sales-data.csv — cabe entero en una pantalla, no hace falta navegar nada.

Con 800,000 líneas: less sales-data.csv (o head/tail si solo necesitas un extremo). cat volcaría las 800,000 líneas de una sola vez, dejándote solo la última pantalla visible y sin forma de volver atrás; less carga el archivo de a partes y te deja navegar y buscar sin imprimirlo todo de golpe.

Ejercicio 2 — Navega con less. Abre /usr/share/dict/words con los números de línea visibles desde el arranque, sin tener que activarlos después. Salta directo a la última línea del archivo. Busca la palabra "terminal" y luego sal del visor sin cerrar la ventana de tu terminal.

Ver solución
less -N /usr/share/dict/words

Dentro del visor: G (salta al final del archivo), ?terminal + Enter (busca hacia atrás, porque ya estás al final — si buscaras con / desde ahí, no habría nada por delante que encontrar), y q para salir.

Por qué funciona: -N activa los números de línea al arrancar en vez de tener que reabrir el archivo con otra bandera; G te lleva al final del archivo con una sola tecla; ? busca hacia atrás desde tu posición actual (mientras que / busca hacia adelante); q cierra el visor sin afectar en nada tu sesión de terminal.

Ejercicio 3 — head y tail con -n. Un archivo server.log tiene 50,000 líneas. Quieres ver únicamente las primeras 3 (para confirmar cuándo arrancó el servicio) y las últimas 3 (para ver el estado más reciente), sin abrir el archivo completo. Escribe los dos comandos.

Ver solución
head -n 3 server.log
tail -n 3 server.log

Por qué funciona: -n 3 le indica explícitamente a cada comando cuántas líneas mostrar, en lugar de aceptar el valor por defecto (10). head cuenta desde el principio del archivo y tail desde el final, y ninguno de los dos necesita cargar las 50,000 líneas completas para hacerlo.

Ejercicio 4 — Troubleshooting. Sin querer corriste cat sobre un archivo .png y ahora tu terminal muestra símbolos raros; cuando escribes, no ves lo que tecleas. ¿Qué haces?

Ver solución
reset

Escríbelo y presiona Enter, aunque no veas las teclas en pantalla mientras lo haces.

Por qué funciona: reset reinicializa la configuración de la terminal a sus valores por defecto — recupera el eco de teclado y el modo de línea normal que las secuencias de escape del binario habían alterado. No borra ningún archivo ni cierra tu sesión, solo repara el estado de la terminal.

Resumen y siguiente paso

Antes de avanzar deberías poder:

  • Medir un archivo con wc -l antes de decidir cómo abrirlo.
  • Elegir cat para archivos cortos y less para archivos largos, sin dudar.
  • Navegar dentro de less: avanzar, retroceder, saltar al principio y al final, buscar con / y ?, y salir con q.
  • Usar head -n y tail -n para asomarte a los extremos de un archivo sin abrirlo completo.
  • Dejar tail -f corriendo para seguir un archivo que sigue creciendo, y saber que Ctrl+C lo detiene.
  • Recuperar tu terminal con reset si abriste un binario por error.

Todo lo que hiciste hoy asume que ya sabías dónde estaba el archivo: lo escribiste tú mismo con touch, o alguien te dio el nombre exacto y la ruta completa. En un proyecto real, con miles de archivos repartidos en decenas de carpetas, esa suposición se cae — vas a necesitar preguntarle al sistema de archivos "¿dónde está esto?" antes de poder leerlo con cualquiera de estas herramientas. Esa es la pieza que falta, y es exactamente lo que resuelve find.

Recursos