Módulo 2: Trabajar con archivos y texto

1. Introducción: crear, encontrar y leer sin abrir un editor

Descripción

Al terminar esta lección vas a poder diferenciar cuándo una pregunta sobre tu propio sistema de archivos se resuelve buscando por nombre, tipo, tamaño o fecha —encontrar dónde vive un archivo— y cuándo se resuelve buscando dentro de su contenido —encontrar qué dice—, y vas a poder explicar con un ejemplo concreto por qué el explorador gráfico de archivos, el que usas a diario con clics, deja de alcanzar apenas un proyecto crece más allá de una carpeta con una docena de archivos.

Esa distinción no es un tecnicismo de este módulo: es la que vas a usar todos los días una vez que trabajes con proyectos reales. Te conectas por SSH a un servidor de producción para revisar un incidente y ahí no hay Finder ni Explorador de Windows —solo una terminal—. Heredas un repositorio de doscientos archivos escrito por alguien que ya no trabaja en la empresa y necesitas saber, antes de subirlo a un repositorio público, si alguien dejó una contraseña escrita a mano en el código. En ambos casos, saber señalar con el mouse ya no te sirve. Saber preguntarle al sistema de archivos, sí.

Conexión con el módulo: el módulo 1 te enseñó a moverte por el árbol de directorios y a mirar qué hay en cada lugar —cd, ls, pwd—. Este módulo te enseña a actuar sobre ese árbol: vas a crear estructura, copiar y mover y borrar con criterio, leer archivos de cualquier tamaño, localizar cualquier archivo de tu máquina y encontrar cualquier línea de texto dentro de un proyecto entero. Esta lección es el mapa completo de ese recorrido, y una advertencia que conviene leer antes de escribir el primer comando: a partir de la lección 3, este módulo te da el poder de borrar cosas para siempre.

La lupa que deja de alcanzar

Piensa en cómo buscas algo en tu propio escritorio, con una docena de archivos sueltos: miras los nombres, reconoces el que buscabas, listo. Ese método funciona porque tu ojo puede recorrer doce nombres en medio segundo y tu memoria ya sabe más o menos qué esperar de cada uno.

Ahora imagina que heredas un proyecto de otra persona: un repositorio con miles de archivos, carpetas de dependencias con cientos de subcarpetas que nunca escribiste tú, nombres que no significan nada para ti todavía. El mismo método —mirar nombres y reconocer— deja de funcionar, no porque seas menos capaz, sino porque el problema cambió de escala. Y si además ese proyecto vive en un servidor al que te conectas por SSH, ni siquiera tienes la opción de abrir una ventana con íconos: no hay ventana. Hay una terminal, una lista de comandos, y nada más.

Ese es el límite real del explorador gráfico de archivos, y tiene tres caras distintas:

Existencia. El explorador gráfico necesita, primero que nada, una interfaz gráfica. Un servidor de producción, un contenedor recién levantado, una máquina virtual a la que entras por SSH: ninguno de esos entornos trae una. Si tu única herramienta de búsqueda depende de clics, en esos lugares no tienes ninguna herramienta de búsqueda.
Precisión combinada. Preguntas como "los archivos de configuración modificados en las últimas 24 horas que además pesan menos de 1 kilobyte" son naturales de expresar en una frase, pero armar esa combinación exacta de criterios a golpe de clic —abrir un panel de filtros, elegir tipo, elegir fecha, elegir tamaño, confirmar— es lento y no queda guardado para repetirlo mañana con un solo gesto.
Contenido a escala. Buscar una palabra dentro de miles de archivos de texto —no su nombre, lo que dice adentro— es exactamente el tipo de tarea para la que un explorador gráfico no fue diseñado: en el mejor de los casos depende de un índice que se construye en segundo plano y puede estar desactualizado; en el peor, simplemente no busca dentro del contenido en absoluto.

find y grep, las dos herramientas que vertebran este módulo, resuelven exactamente esas tres cosas: no necesitan más que una terminal para existir, combinan cualquier cantidad de criterios en una sola línea, y leen el contenido completo de miles de archivos en el tiempo que tarda en parpadear un cursor. Son, minuto por minuto de práctica invertido, probablemente las dos habilidades de mayor rendimiento de toda esta guía: un par de horas para entenderlas bien te van a ahorrar, de por vida, la cantidad de veces que abres un explorador de archivos y navegas carpeta por carpeta esperando reconocer algo a ojo.

Ejemplo trabajado: la misma pregunta, dos maneras de responderla

Imagina que heredas este proyecto de un compañero que ya dejó la empresa:

unfamiliar-project/
├── config/
│   ├── database.yaml
│   └── secrets.env
├── src/
│   ├── index.js
│   └── payments.js
├── tests/
│   └── payments.test.js
├── vendor/
│   └── lodash/
│       └── index.js
└── notes.txt

Te piden algo puntual antes de subirlo a un repositorio público: confirmar que nadie dejó una credencial escrita a mano en el código.

Con un explorador gráfico, el camino sería abrir config/, mirar cada archivo uno por uno, abrir src/, hacer lo mismo, decidir si vale la pena entrar a vendor/lodash/ (una carpeta de una dependencia externa que ni siquiera escribiste tú, pero que técnicamente también hay que descartar), y confiar en que tu ojo no se salte ninguna línea larga dentro de un archivo con código. Con cinco archivos como en este ejemplo, es tedioso pero posible. Con los quince mil archivos que trae de verdad cualquier proyecto con dependencias instaladas, es prácticamente imposible hacerlo a conciencia.

Así se ve la misma pregunta resuelta desde la terminal. Todavía no hace falta que entiendas cada palabra —find lo aprendes a fondo en la lección 5 y grep en la lección 6—; por ahora, mira solo la forma y el resultado:

find unfamiliar-project -name "*.env"

Qué esperar:

unfamiliar-project/config/secrets.env

Un archivo .env —la extensión que casi cualquier proyecto usa para credenciales— apareció de inmediato, sin que tuvieras que abrir una sola carpeta a mano. Ahora miras qué hay adentro, y de paso confirmas si esa misma credencial se usa en algún otro lugar del código:

grep -rn "API_KEY" unfamiliar-project

Qué esperar:

unfamiliar-project/config/secrets.env:1:API_KEY=sk-live-FAKEEXAMPLE12345
unfamiliar-project/src/payments.js:1:const STRIPE_API_KEY = process.env.API_KEY;

Dos líneas, en dos archivos distintos, con el número de línea exacto de cada una: la credencial en sí, dentro de secrets.env, y la referencia a esa credencial dentro de payments.js. Ninguno de los dos comandos abrió un editor ni exigió que supieras de antemano en qué carpeta buscar. find contestó "dónde" —un archivo, entre siete—; grep contestó "qué dice el contenido" —dos líneas, entre siete archivos completos—. Esa es la frontera exacta entre las lecciones 5 y 6, y vas a volver a ver este mismo par de comandos, ya explicados en detalle, cuando llegues ahí.

El mapa del módulo

Este módulo sigue un orden deliberado, y conviene que lo veas completo antes de la primera línea de código: primero aprendes a crear estructura, porque no hay nada que romper creando carpetas vacías; después aprendes a copiar, mover y borrar, con la seguridad enseñada codo a codo con el comando —de esto habla la advertencia de abajo—; después aprendes a leer archivos completos sin que tu terminal quede inservible; recién con esas tres piezas en la mano llegas a find y grep, las dos herramientas de localización de esta lección; cierras con edición de texto directamente en la terminal, y con un proyecto que junta todo contra un directorio que nunca viste.

1. Introducción: crear, encontrar y leer sin abrir un editor    ← estás aquí
2. Crear archivos y carpetas: mkdir y touch
3. Copiar, mover y borrar sin destruir nada
4. Leer archivos: cat, less, head y tail
5. Encontrar archivos con find
6. Buscar dentro de archivos con grep
7. Editar en la terminal: nano y supervivencia en vim
8. Proyecto: auditar un proyecto que no conoces

El proyecto final (lección 8) te entrega un directorio ajeno, parecido al unfamiliar-project/ del ejemplo de arriba pero mucho más grande y desordenado, y te pide exactamente lo que acabas de ver: ubicarte, entender qué hay y dejarlo en condiciones — usando cada pieza de este módulo, no solo find y grep.

Advertencia temprana: aquí sí se puede romper algo de verdad

En el módulo 1 no había mucho riesgo: mirar un directorio con ls o moverte con cd no cambia nada de lo que hay en el disco. La próxima lección tampoco lo tiene —crear una carpeta vacía con mkdir no destruye nada—. Pero la lección 3, la que sigue después, introduce rm, y con rm este módulo cruza una línea que no existía hasta ahora: por primera vez en esta guía, un comando mal escrito puede borrar algo para siempre, sin papelera de reciclaje de por medio y sin un botón de deshacer.

Por eso esta guía no separa "aquí está el comando" de "aquí están las precauciones" en dos momentos distintos, como hacen muchos tutoriales que muestran rm -rf primero y agregan la advertencia de seguridad como una nota al pie, si es que la agregan. En la lección 3 vas a aprender el criterio de seguridad —listar antes de borrar, desconfiar de los comodines, verificar variables vacías— en la misma respiración en la que aprendes el comando, no después. Tenlo presente desde ya: cuando llegues ahí, la tentación va a ser copiar el comando y seguir de largo. Resístela una lección más; vas a agradecerlo la primera vez que casi borras algo que no ibas a poder recuperar.

Errores comunes

Pensar que la búsqueda del explorador gráfico y la de la terminal resuelven el mismo problema, solo que una con clics y la otra con texto (conceptual). No es así: cambian de escala y de entorno, no solo de forma. El explorador gráfico funciona razonablemente bien en tu propio escritorio, con carpetas de tamaño humano y una interfaz disponible; find y grep están hechos para lo que el explorador gráfico no puede hacer en absoluto —combinar varios criterios a la vez, operar sobre miles de archivos en segundos, funcionar en un servidor remoto sin ninguna interfaz—. Cómo se detecta: si tu plan frente a un proyecto heredado grande sigue siendo "voy a abrir carpetas y mirar", es momento de recordar el ejemplo de esta lección. Cómo se corrige: antes de abrir una sola carpeta a mano, pregúntate si la respuesta es sobre dónde está algo o sobre qué dice el contenido, y elige find o grep en consecuencia.

Asumir que la terminal tiene, por defecto, una papelera de reciclaje como la del escritorio (conceptual). Es un supuesto razonable si lo único que conocías hasta ahora era arrastrar archivos a una papelera y poder recuperarlos después. En la terminal, salvo que instales una herramienta aparte para eso —algo que vas a ver como opción en la lección 3—, no existe: rm borra, y no hay un segundo paso para arrepentirse. Cómo se detecta: si al pensar en borrar algo por terminal tu plan mental incluye "y si me arrepiento, lo recupero después" sin haber verificado que eso es cierto, el supuesto está sin confirmar. Cómo se corrige: trata cada operación de borrado en la terminal como si no existiera forma de deshacerla, hasta que la lección 3 te muestre exactamente cuáles son tus opciones reales.

Querer saltar directo a find o grep porque son "las herramientas interesantes", sin pasar antes por crear, copiar/mover/borrar y leer archivos. Es una tentación entendible: son las dos habilidades que este módulo promociona más fuerte, y acabas de ver en el ejemplo de arriba lo que pueden hacer. El problema es que las lecciones 2 a 4 no son relleno antes de llegar a lo bueno: te dan el vocabulario de archivos y carpetas con el que vas a construir los árboles de práctica de las lecciones 5 y 6, y el criterio de seguridad que vas a necesitar en cuanto find te ofrezca borrar en lote con -delete. Cómo se detecta: si te encuentras copiando comandos de find de otro lado sin poder explicar en qué carpeta estás parado ni qué archivo se perdería si el comando falla. Cómo se corrige: respeta el orden del mapa una vez; el resto de tu carrera con la terminal ya no vas a necesitar que nadie te lo recuerde.

Ejercicios

Ejercicio 1 — Explorador gráfico o terminal. Para cada escenario, decide si el explorador gráfico de archivos te alcanza o si necesitas la terminal, y justifica con las tres caras del límite que viste en esta lección: existencia de una interfaz, precisión combinada de criterios, y búsqueda de contenido a escala.

Buscas una foto que sacaste ayer, en una carpeta de vacaciones con veinte fotos, y sabes más o menos cómo se llama.
Te conectas por SSH a un servidor remoto y necesitas encontrar, entre miles de archivos de log, cuáles se modificaron en la última hora.
En tu proyecto local de cinco mil archivos, necesitas saber en cuáles se usa todavía una función que estás por eliminar.

Ver solución

Explorador gráfico. Veinte fotos es una escala donde el ojo humano funciona bien, tienes una interfaz disponible en tu propia máquina, y no necesitas combinar criterios: solo reconocer un nombre aproximado.
Terminal, sin alternativa. Un servidor remoto por SSH no tiene interfaz gráfica —el primer límite de la lista—, así que la pregunta ni siquiera se puede intentar con un explorador de archivos. Es el caso de find filtrando por fecha de modificación.
Terminal. Encontrar dónde se usa una función significa buscar dentro del contenido de miles de archivos, no por su nombre —el tercer límite—. Es un trabajo de grep, y hacerlo a ojo en cinco mil archivos no es viable en la práctica.

Por qué funciona: el criterio no es "la terminal siempre gana". Es notar cuál de los tres límites —existencia de interfaz, combinación de criterios, contenido a escala— está presente en cada escenario, y ese límite es justamente el que el explorador gráfico no resuelve.

Ejercicio 2 — ¿Dónde está o qué dice? Para cada pregunta, decide si la respondería mejor find (busca por metadata: nombre, tipo, tamaño, fecha) o grep (busca dentro del contenido). No hace falta que sepas la sintaxis todavía —solo identifica el tipo de pregunta.

"¿Cuál es el archivo de configuración más pesado de este proyecto?"
"¿En qué archivo se define la función calculateTotal?"
"¿Qué archivos se modificaron en las últimas 24 horas?"
"¿Aparece la palabra TODO en algún comentario del proyecto?"

Ver solución

find — la pregunta es sobre una propiedad del archivo (tamaño), no sobre su contenido.
grep — necesitas encontrar dónde aparece un texto específico (el nombre de la función) dentro del código, sin saber de antemano en qué archivo vive.
find — otra vez metadata, esta vez fecha de modificación.
grep — de nuevo, buscar una palabra dentro del contenido de los archivos.

Por qué funciona: la pregunta clave es si la respuesta depende de cómo se llama, cuánto pesa o cuándo se tocó el archivo (metadata → find) o de qué hay escrito adentro (contenido → grep). Esa frontera es exactamente la que separa las lecciones 5 y 6, y reconocerla de antemano te ahorra intentar la herramienta equivocada primero.

Ejercicio 3 — Antes de conocer el comando. Todavía no aprendiste rm ni sus banderas de seguridad —llegan en la lección 3—, pero ya sabes, por esta lección, un hecho central sobre él: no hay papelera de reciclaje por defecto. Con solo ese hecho, explica en dos o tres frases qué hábito adoptarías antes de ejecutar cualquier comando de borrado en la terminal, incluso sin conocer todavía la sintaxis exacta.

Ver solución

No hay una única redacción correcta, pero la idea central debería ser: antes de borrar algo por terminal, hay que confirmar exactamente qué se va a borrar —por ejemplo, mirándolo primero con algún comando que solo liste, sin tocar nada— y no asumir que existe una segunda oportunidad después. El hábito no depende de la sintaxis específica de rm: depende de tratar cualquier borrado como irreversible por defecto, hasta que se demuestre lo contrario.

Por qué funciona: el hecho de que la terminal no tenga papelera por defecto no es un detalle técnico menor, es la razón por la que la lección 3 enseña la seguridad junto con el comando. Adoptar el hábito de verificar antes de borrar, incluso antes de saber la sintaxis exacta, es exactamente la actitud que esa lección va a formalizar con reglas concretas.

Resumen y siguiente paso

Viste por qué el explorador gráfico de archivos —útil en tu propio escritorio— deja de alcanzar apenas un proyecto crece o vive en un servidor remoto sin interfaz, y por qué find (localizar por metadata) y grep (localizar por contenido) son, minuto por minuto de práctica, dos de las herramientas de mayor rendimiento de esta guía. También viste el mapa completo del módulo y una advertencia que conviene no olvidar: a partir de la próxima lección empiezas a crear, y desde la lección 3 tienes en las manos un comando, rm, que puede borrar algo para siempre.

Antes de avanzar deberías poder:

Explicar, con tus propias palabras, las tres razones por las que un explorador gráfico de archivos deja de alcanzar en un proyecto real.
Distinguir si una pregunta sobre archivos es de tipo "dónde" (metadata, find) o de tipo "qué dice" (contenido, grep), sin todavía saber escribir el comando.
Nombrar, sin mirar el mapa, qué lección introduce el primer comando de este módulo capaz de destruir datos, y por qué esta guía enseña su seguridad junto con el comando y no después.

Lo que sigue no es todavía buscar. Antes de encontrar algo, necesitas poder crear la estructura sobre la que vas a practicar el resto del módulo: carpetas y archivos, con mkdir y touch, incluyendo una forma de crear varios de una sola vez que vas a usar en casi todos los ejemplos que quedan por delante.

Recursos

find(1) — Linux manual page — referencia completa de find, la utilidad que vas a aprender a fondo en la lección 5.
grep(1) — Linux manual page — referencia completa de grep, que vas a aprender a fondo en la lección 6.
GNU Findutils Manual — referencia completa de find, la versión de GNU que corre en casi cualquier distribución de Linux.
GNU Grep Manual — referencia completa de grep, incluidas las opciones de búsqueda recursiva que vas a usar desde el primer ejemplo de la lección 6.
GNU Coreutils Manual — rm invocation — la referencia oficial del comando que la advertencia de esta lección te pide tratar con respeto desde ya; el detalle completo llega en la lección 3.

← Anterior8. Proyecto: búsqueda del tesoro por tu máquina Siguiente →2. Crear archivos y carpetas: mkdir y touch