Hasta ahora todo lo que has ejecutado era inofensivo: mirar, listar, consultar. Esta lección cruza la línea. A partir de aquí los comandos escriben en el disco, y algunos de ellos borran sin preguntar y sin posibilidad de deshacer.

No es una advertencia retórica. En Linux no hay papelera de reciclaje por defecto: rm desenlaza el archivo y el espacio queda disponible para reutilizarse. Recuperar algo borrado en un sistema de archivos montado y en uso es, en la práctica, imposible. Por eso esta lección dedica un apartado entero a estrategias defensivas, y por eso el snapshot de la VM es hoy más importante que nunca.

A cambio, estas son las herramientas con las que se trabaja de verdad: crear estructuras de directorios, copiar preservando permisos, mover y renombrar, sincronizar árboles completos y empaquetar software para distribuirlo. Al terminar podrás preparar un paquete de /opt/tramontana/app listo para enviárselo a Luis, con la certeza de que llegará idéntico a como salió.

1. touch: crear y tocar marcas de tiempo
2. mkdir y rmdir: estructura de directorios
3. cp: copiar, y la trampa de la barra final
4. mv: mover y renombrar
5. rm: la conversación seria
6. Renombrado por lotes con rename
7. rsync: la forma correcta de copiar directorios
8. tar: empaquetar
9. Compresión: gzip, bzip2, xz y zip
10. Práctica: preparar el paquete para Luis

touch hace dos cosas distintas según el archivo exista o no:

• Si no existe, lo crea vacío.
• Si existe, actualiza sus marcas de tiempo sin tocar el contenido.

Cero bytes: existe pero está vacío. Acepta varios argumentos:

La segunda función, actualizar marcas de tiempo, es la que da nombre al comando y la que sorprende a quien solo lo conoce como «crear archivo vacío». Retomando las tres marcas de la lección anterior:

Fíjate en lo que no ha cambiado:

El mtime dice enero, pero el ctime dice hoy. Es exactamente lo que anticipaba el ejercicio de la lección 02-03: puedes falsificar el mtime, pero el ctime delata que el inodo se tocó ahora mismo.

Usos legítimos de touch en administración:

• Crear un archivo de bloqueo o un marcador (/var/run/tramontana.lock).
• Forzar que una herramienta que compara fechas considere un archivo como modificado.
• Fijar la fecha de un archivo restaurado de una copia para que coincida con el original.
• Crear un archivo vacío antes de darle permisos restrictivos y luego escribir en él, para que nunca exista con permisos abiertos.

-c es la opción defensiva: actualiza si existe, y si no existe no hagas nada. Evita crear archivos vacíos por una errata en el nombre.

Sin -p, mkdir no crea rutas anidadas:

-p tiene una segunda propiedad, tan importante como la primera: no falla si el directorio ya existe.

Eso hace que mkdir -p sea idempotente: ejecutarlo diez veces deja el sistema en el mismo estado que ejecutarlo una. Es la propiedad que se busca en scripts, donde un mkdir que falla porque el directorio ya existía abortaría la ejecución sin motivo. Lo retomarás en el Módulo 4 y con Ansible en el Módulo 7.

-m crea con permisos concretos en una sola operación:

Es mejor que crear y luego hacer chmod, porque entre las dos operaciones existiría una ventana —breve, pero real— en la que el directorio tiene permisos más abiertos de lo debido. En un sistema multiusuario, esa ventana es un problema de seguridad. El significado del 700 es la lección 02-07.

Con expansión de llaves puedes crear estructuras completas de una vez:

Esas llaves son expansión de llaves, una función del shell que se explica en la lección 03-02. Úsala ya; entenderás su mecánica más adelante.

rmdir borra un directorio, pero solo si está vacío:

Esa limitación no es un defecto: es una red de seguridad. rmdir no puede borrar nada por accidente porque solo actúa sobre directorios vacíos. Cuando quieras eliminar un directorio con contenido tendrás que usar rm -r, y en ese momento estás asumiendo conscientemente el riesgo.

rmdir -p elimina la rama entera mientras vaya quedando vacía:

Borró agosto, luego 2026 porque quedó vacío, y luego informes.

Las opciones que importan:

cp sobrescribe sin avisar. Es el comportamiento por defecto y ha destruido mucho trabajo:

reservas.csv ya no contiene reservas: contiene casas. No hubo ni un aviso.

Compara con la versión defensiva:

Diferencia entre -p y -a:

La copia normal tiene la fecha de hoy; la copia con -p conserva la fecha original. El propietario cambió en ambas porque operador no puede crear archivos que pertenezcan a root (hace falta sudo; los detalles en la lección 02-07).

Regla práctica: para copiar un árbol de directorios tal cual, cp -a. Para todo lo demás, cp -r basta.

Este es el comportamiento que más confusión genera de todo el comando. La clave: cp se comporta de forma distinta según el destino exista y sea un directorio o no.

En el caso 2, el archivo se llama respaldo/casas.txt. Hasta aquí es intuitivo. La sorpresa aparece con directorios:

El mismo comando produce dos resultados distintos según si respaldo existía. Ese es el fallo clásico: ejecutas un script de copia dos veces y la segunda te crea respaldo/datos/ anidado dentro.

Y ahora la barra final en el origen, que en cp no cambia nada pero en rsync lo cambia todo:

Con cp, datos y datos/ dan el mismo resultado. En rsync no, como verás en el apartado 7. Es una de las incoherencias históricas de Unix con las que hay que convivir.

Defensa práctica: cuando copies directorios, ejecuta antes ls -d destino para saber si existe. Y en scripts, usa siempre destinos explícitos y comprobados.

mv hace las dos cosas con el mismo comando, porque en el fondo son la misma operación: cambiar la entrada de directorio que apunta a un archivo.

Como cp, mv sobrescribe sin preguntar, y con una diferencia crucial: en cp pierdes solo el destino; en mv pierdes el destino y el origen deja de estar donde estaba.

Este detalle explica un comportamiento que desconcierta cuando mueves archivos grandes.

El mismo inodo. No se ha copiado ni un byte: solo se ha borrado una entrada de directorio y se ha creado otra apuntando al mismo inodo. Por eso mover un archivo de 40 GB dentro del mismo disco es instantáneo.

Ahora, entre sistemas de archivos distintos:

Consecuencias prácticas de la rama derecha:

• Tarda: mover 40 GB de / a un disco USB implica leer y escribir 40 GB.
• Necesita espacio libre en el destino durante toda la operación.
• Si se interrumpe a mitad (corte de luz, Ctrl+C), el destino queda con un archivo parcial y el origen puede haberse borrado parcialmente si eran varios archivos. mv no es atómico entre sistemas de archivos.
• El ctime cambia y el propietario puede cambiar, porque en realidad se ha creado un archivo nuevo.

Cómo saber si dos rutas están en el mismo sistema de archivos:

Mismo dispositivo, /dev/sda2: el movimiento será instantáneo. Si aparecieran dispositivos distintos, sería copiar y borrar.

Regla para mover cosas grandes entre discos: usa rsync y borra después, tras verificar. Así, si algo falla, el origen sigue intacto.

rm elimina archivos. En un sistema de archivos montado y en uso, lo hace de forma irreversible.

-I es el punto dulce: te para a pensar una vez, sin la fatiga de -i preguntando cuatrocientas veces (que acaba haciendo que respondas «sí» automáticamente, que es peor que no preguntar).

rm -rf es la combinación que borra un árbol completo sin una sola pregunta y sin quejarse de nada. Es necesaria en scripts y es la responsable de la mayoría de los desastres de datos autoinfligidos.

El caso paradigmático es el de la variable vacía. Un script contiene:

Si por cualquier motivo DESTINO y SUBDIR están vacías —porque un cd previo falló, porque un fichero de configuración no se leyó, porque hubo una errata en el nombre de la variable— la línea que se ejecuta es:

Este error ha ocurrido en empresas reales y ha llegado a borrar sistemas enteros en producción. El caso más conocido públicamente es el de un instalador de un juego comercial que, por esta misma causa, borraba el directorio personal completo de sus usuarios.

Las versiones modernas de rm incluyen --preserve-root, que rechaza rm -rf /:

Pero esa protección solo cubre la raíz exacta. rm -rf /home o rm -rf /opt/tramontana se ejecutan sin objeción. Y con la barra: rm -rf "$DESTINO"/ cuando DESTINO está vacía da rm -rf /, protegido; pero rm -rf "$DESTINO"/* con DESTINO vacía da rm -rf /*, que no está protegido y borra todo el contenido de la raíz.

1. Mirar antes de borrar. El hábito que ya conoces, ahora obligatorio:

Y con patrones, más aún: ejecuta el ls con el mismo patrón, comprueba la lista y solo entonces cambia ls por rm con la flecha arriba.

2. Usar -I por costumbre en trabajo interactivo.

3. Papelera con trash-cli. Existe un equivalente a la papelera de escritorio para la terminal:

Es útil en tu portátil. En un servidor tiene un inconveniente serio: los archivos siguen ocupando espacio en ~/.local/share/Trash, y si borrabas para liberar disco, no has liberado nada. Úsalo con criterio.

4. Alias defensivos. Se puede hacer que rm sea rm -I por defecto mediante un alias. Los aliases se estudian en la lección 03-01, y allí discutiremos por qué esta práctica concreta es discutible: te acostumbras a una protección que no existe en los demás servidores, y el día que trabajes en una máquina ajena tendrás una falsa sensación de seguridad.

5. Comillas y --. Entrecomilla siempre las variables y usa -- antes de nombres que vengan de fuera.

6. Lo que de verdad te salva: copias de seguridad. Ninguna de las medidas anteriores protege contra un borrado deliberado y bien escrito. Lo único que protege es tener copias en otro sitio, y eso es la lección 05-08. Y en tu laboratorio, el snapshot de la VM.

Una última nota técnica: rm no borra el contenido, solo desenlaza el nombre. Los datos siguen en los bloques hasta que se sobrescriben. Eso significa dos cosas opuestas: que un forense podría recuperarlos, y que tú, en la práctica, no vas a poder porque el sistema seguirá escribiendo encima mientras lo intentas. Para borrado seguro real existe shred, con sus propias limitaciones en discos SSD y sistemas con journal.

Renombrar cincuenta archivos a mano no es opción. rename (la versión Perl, que es la de Debian y Ubuntu) aplica una transformación a muchos nombres:

-n (o --nono) es obligatorio en la primera ejecución: muestra lo que haría sin hacerlo. Es el equivalente al «mirar antes de actuar» para renombrados masivos.

Más ejemplos:

La sintaxis s/patrón/reemplazo/ son expresiones regulares de Perl, tema de la lección 03-02. De momento te basta con el patrón literal y -n para verificar.

Cuidado con dos cosas: en algunas distribuciones (Fedora, RHEL) rename es un programa completamente distinto con otra sintaxis, y rename sobrescribe sin avisar si el nombre destino ya existe. Añade -v para ver qué hace realmente.

rsync está diseñado para sincronizar árboles de directorios. Frente a cp -a tiene tres ventajas que lo hacen la herramienta por defecto en cuanto la copia es grande o importante:

Segunda ejecución, sin cambios:

162 bytes en vez de 50 MB. Ha comparado y no ha encontrado nada que copiar. Ese es el ahorro que justifica usar rsync para cualquier cosa que se repita.

Opciones esenciales:

Aquí sí, y es el error número uno con esta herramienta:

Mnemotecnia: la barra final significa «el contenido de». Sin barra, «la carpeta misma».

--delete combinado con esto es peligroso, porque borra en el destino todo lo que no esté en el origen. Si te equivocas de nivel, vacías el destino. Siempre -n primero:

-n te ha enseñado que iba a borrar obsoleto.txt. Ahora decides con información.

El uso de rsync para copias de seguridad reales —con rotación, copias incrementales enlazadas y destinos remotos— es la lección 05-08. Aquí lo usas como el cp bueno para directorios.

tar (tape archive) junta muchos archivos en uno solo conservando la estructura, los permisos y las fechas. Por sí mismo no comprime: eso lo hace un compresor externo al que llama.

Los tres modos de operación son excluyentes, como averiguaste leyendo el manual en la lección 02-02:

Y las opciones que acompañan:

Crear:

Desglose de la orden, que es lo importante:

• -c crear, -z comprimir con gzip, -v mostrar, -f seguido del nombre del archivo resultante.
• -C /opt/tramontana hace que tar se sitúe ahí antes de empaquetar. Sin esto, empaquetaría opt/tramontana/app/... con toda la jerarquía dentro.
• app es lo que se empaqueta, ya relativo a -C.

Listar antes de extraer es obligatorio:

Por qué es obligatorio: para comprobar que el archivo tiene un directorio raíz único. Si en lugar de app/... vieras los ficheros sueltos en la raíz del paquete, al extraerlo te esparciría decenas de archivos por tu directorio actual. Es lo que se conoce como tarbomb, y limpiarlo a mano es tedioso.

Extraer:

Extraer siempre con -C a un directorio vacío evita el problema del tarbomb por completo.

Las versiones modernas de tar detectan la compresión automáticamente al extraer, así que -z, -j o -J no son necesarios para descomprimir. Sí lo son al crear, porque ahí tar no puede adivinar qué quieres.

Excluir lo que no debe viajar:

Y una nota que vale oro: la sintaxis histórica de tar admite las opciones sin guion (tar czf) porque es anterior a la convención de guiones de POSIX. Ambas funcionan. Usa la de guiones, que es la que se entiende.

Los compresores de Unix trabajan sobre un solo archivo y por defecto sustituyen el original:

datos.csv ya no existe: se ha convertido en datos.csv.gz. Para conservar el original hay que pedirlo con -k:

Comparativa sobre un archivo de texto de 100 MB, que es donde estas diferencias se notan:

La regla de decisión:

• Comprimes muchas veces y descomprimes pocas (logs rotados a diario): gzip. La velocidad importa más que el tamaño.
• Comprimes una vez y descomprimes muchas (una release que se descargará mil veces): xz. El tiempo de compresión se paga una sola vez y ahorras ancho de banda en cada descarga.
• Se lo pasas a alguien con Windows: zip.

zip es el único que archiva y comprime a la vez, como en Windows:

Su gran limitación en Linux: no preserva bien los permisos ni la propiedad de Unix. Si empaquetas con zip y desempaquetas, los bits de ejecución pueden perderse y el script deja de funcionar. Por eso en Linux se usa tar, que sí los conserva, y zip solo cuando el destinatario usa Windows.

Herramientas para trabajar con archivos comprimidos sin descomprimirlos, muy útiles con logs:

Luis Ferrer necesita una copia exacta de la versión 3.2.1 desplegada en producción para reproducir un fallo en su portátil. Marta ha aprobado enviársela. El paquete no debe incluir logs ni ficheros temporales, y tiene que llegar íntegro.

Paso 1: verificar qué vas a empaquetar.

Paso 2: crear el directorio de trabajo. No se empaqueta en /tmp a secas: se usa un sitio con espacio y donde el archivo no desaparezca en el próximo reinicio.

Paso 3: empaquetar, excluyendo lo que no debe salir.

Paso 4: verificar el resultado. Nunca envíes un paquete que no has listado.

48 MB comprimidos a 19 MB, un solo directorio raíz app/, permisos preservados (fíjate en el -rwxr-xr-x del ejecutable) y ningún .log dentro.

Paso 5: generar una suma de comprobación para que Luis pueda verificar que el archivo ha llegado íntegro. Es el mismo mecanismo que usaste al verificar la ISO de Ubuntu en la lección 01-04.

Luis, al recibirlo, ejecuta:

Paso 6: prueba de extracción en local. Comprobar que el paquete se abre bien antes de enviarlo, no después de que Luis diga que no funciona.

diff -rq compara dos árboles recursivamente e informa solo de las diferencias. Sin salida y con código 0: son idénticos. Verás diff en detalle en la lección siguiente.

Paso 7: limpiar.

Procedimiento completo, reproducible y verificado. La transferencia del archivo a Luis se hará con scp o rsync sobre SSH, que es la lección 06-02.

Olvidar -r al copiar o borrar directorios. cp: se omite el directorio y rm: no se puede borrar: es un directorio son el mismo aviso.

La barra final. En cp casi no importa; en rsync decide si copias la carpeta o su contenido. Y en cp -r, el resultado depende de si el destino ya existía.

cp y mv sobrescriben en silencio. No hay confirmación por defecto. -i o -n cuando el destino pueda existir.

Copiar configuración con cp en vez de cp -p. Pierdes las fechas, que muchas veces son la única pista de cuándo se cambió algo.

Empaquetar con rutas absolutas. tar -czf x.tar.gz /opt/tramontana/app guarda la jerarquía opt/tramontana/app/ dentro. Usa -C y rutas relativas.

Extraer sin listar primero. tar -tzvf antes de tar -xzf, siempre.

zip para archivos de Linux. Pierde bits de ejecución y propiedad. tar para Linux, zip solo para Windows.

Consejo: rsync -n y rename -n antes de la versión real. El modo simulación es gratis y te enseña exactamente lo que va a pasar.

Consejo: nombra los paquetes con versión y fecha. tramontana-app-3.2.1.tar.gz es informativo; backup.tar.gz no dice nada dentro de tres meses.

Consejo: acompaña siempre un paquete de su sha256sum. Cuesta un comando y elimina toda una categoría de incidencias.

Consejo: antes de un rm -r, pulsa Ctrl+A y escribe ls -la delante. Miras, y luego flecha arriba y lo cambias por el rm. Diez segundos que han salvado muchos datos.

En tu home de srv-tramontana, con el mínimo número de comandos:

1. Crea la estructura trabajo/2026/{07,08,09}/informes y trabajo/2026/{07,08,09}/datos.
2. Crea un archivo trabajo/2026/08/informes/resumen.txt con fecha de modificación del 1 de agosto de 2026 a las 09:00.
3. Copia ~/datos/reservas.csv a trabajo/2026/08/datos/ preservando sus marcas de tiempo, y verifícalo.
4. Renombra todos los .txt de trabajo/2026/08/informes/ a .md sin equivocarte (usa el modo simulación).

Luis te propone este procedimiento para hacer una copia diaria de la aplicación antes de cada despliegue:

Encuentra al menos cinco problemas y reescribe el procedimiento correctamente.

Marta necesita llevarse a una reunión los datos de reservas y el listado de casas. Trabaja con Windows y quiere abrir los archivos con Excel. Además pide que el paquete incluya un pequeño informe de qué contiene.

Prepara el envío completo: crea el informe, empaqueta en el formato adecuado, verifica el contenido del paquete y genera la suma de comprobación. Justifica la elección del formato de compresión.

Solución 1

Un solo comando. La expansión de llaves anidada genera las seis combinaciones y -p crea todos los padres. Sin -p fallaría porque trabajo y trabajo/2026 no existen.

touch con -t crea y fija la marca en una sola operación. El formato es AAAAMMDDhhmm.ss.

Las marcas coinciden al nanosegundo. Sin -p, la copia tendría la fecha de ahora. Fíjate en que el destino termina en /: como el directorio existe, la copia se hace dentro conservando el nombre.

El \. escapa el punto para que signifique un punto literal y no «cualquier carácter», y el $ ancla el patrón al final del nombre, de modo que un archivo llamado notas.txt.viejo no se vería afectado. Ambas cosas son expresiones regulares (lección 03-02).

Solución 2

Los problemas del procedimiento de Luis:

1. Ambos comandos sobrescriben el respaldo anterior sin avisar. El nombre app-backup y app.tar.gz son fijos. Cada día se pisa la copia del día anterior, así que en realidad solo existe una copia: la de ayer. Si el problema se detecta dos días después, no hay a qué volver.

2. Peor aún: se sobrescribe antes de saber si el despliegue va bien. Si el despliegue de hoy falla y ya has machacado la copia buena con la copia de la versión rota, has perdido el punto de retorno.

3. cp -r no preserva permisos ni propietarios. El ejecutable puede perder su bit de ejecución y todo pasa a pertenecer al usuario que ejecuta el comando. Restaurar esa copia dejaría la aplicación sin arrancar. Debe ser cp -a o, mejor, rsync -a.

4. tar czf con ruta absoluta. Guarda la jerarquía opt/tramontana/app/ dentro del paquete. Al extraer no obtienes app/, sino tres niveles de directorios, y tar avisa con «eliminando la / inicial de los nombres». Falta -C.

5. Se hacen dos copias redundantes de lo mismo, una sin comprimir (48 MB) y otra comprimida (19 MB), ocupando 67 MB por despliegue sin que ninguna aporte nada que la otra no tenga.

6. No hay verificación. Nadie comprueba que el .tar.gz se pueda abrir ni que contenga lo que debe. Una copia que no se ha verificado no es una copia: es una suposición.

7. No hay ningún control de espacio. Si /srv se llena a mitad del tar, queda un archivo truncado que parece una copia válida.

Procedimiento reescrito:

Correcciones aplicadas:

• Nombre con fecha y hora: cada ejecución crea un archivo distinto. Nunca se pisa nada.
• Un solo paquete comprimido en vez de dos copias.
• -C /opt/tramontana app: dentro del paquete hay un único app/ limpio.
• tar preserva permisos y propietarios por diseño, así que no hace falta -a.
• || exit 1 en cada paso crítico: si algo falla, el script para en vez de continuar como si nada. Es el &&/|| de la lección 02-01 aplicado.
• Verificación con tar -tzf antes de dar la copia por buena.
• Suma de comprobación para detectar corrupción posterior.

Lo que aún le falta y llegará en su momento: rotación (borrar copias de más de N días para que /srv no crezca sin fin), que se hace con find -mtime en la lección 03-03; automatización con cron (03-07); y destino remoto, porque una copia en el mismo disco que el original no protege contra un fallo de hardware (05-08).

Cómo decírselo a Luis: su procedimiento hace el gesto de copiar pero no cumple ninguna de las tres propiedades de una copia útil —única, verificable y restaurable—. Y la más grave es la primera: al usar un nombre fijo, la copia buena se destruye justo antes de que la necesites.

Solución 3

Elección del formato: zip. Marta trabaja en Windows y va a abrir los archivos con Excel. Aunque en Linux tar.gz conserva mejor los metadatos, aquí eso no aporta nada —son ficheros de datos, no ejecutables— y sí supondría que Marta tuviera que instalar una herramienta para abrirlo. Windows abre .zip de forma nativa con doble clic. La compatibilidad con el destinatario manda sobre la pureza técnica.

(Ese cat > fichero <<'FIN' es un here document: escribe todo el bloque en el archivo. Se explica en el Módulo 3; aquí lo usas como herramienta.)

Detalles del procedimiento que merecen comentario:

• cd al directorio y zip * en vez de zip -r /tmp/x.zip /tmp/envio-marta: así el paquete contiene los tres archivos en su raíz, sin la jerarquía tmp/envio-marta/ dentro. Es el equivalente del -C de tar.
• cp -p conserva las fechas originales de los datos, visibles en el listado del zip. Marta puede ver que casas.txt es de ayer y reservas.csv de esta mañana.
• El LEEME resuelve por adelantado la pregunta que Marta habría hecho por teléfono: por qué el CSV se ve mal en Excel. El separador punto y coma es el que usa reservas.csv, y en un Excel con configuración regional española suele funcionar directamente, pero conviene documentarlo.
• La suma de comprobación va en un archivo aparte, no dentro del zip: tiene que poder verificarse sin abrir el paquete.

Nota importante para el mundo real: reservas.csv contiene nombres de huéspedes, es decir, datos personales. Enviar ese archivo fuera del servidor por correo o por un canal no cifrado tiene implicaciones de protección de datos. En un entorno real, este envío debería ir cifrado y contar con la aprobación del responsable de protección de datos. Volveremos sobre el cifrado de archivos en la lección 06-05.

Ya escribes en el disco, y lo haces con red de seguridad.

• touch crea archivos vacíos y manipula marcas de tiempo, y su ctime siempre delata la manipulación.
• mkdir -p es idempotente y crea árboles completos; rmdir es seguro por diseño porque solo borra lo vacío.
• cp sobrescribe en silencio; -a es la opción para copias fieles; y la trampa de la barra final y del destino preexistente produce resultados distintos con el mismo comando.
• mv es instantáneo dentro del mismo sistema de archivos porque solo cambia una entrada de directorio, y es copiar-y-borrar, lento y no atómico, cuando cruza a otro.
• rm es irreversible, rm -rf con una variable vacía ha borrado sistemas enteros, y las defensas son mirar antes, -I, comillas y, sobre todo, copias de seguridad.
• rename -n renombra por lotes con simulación previa.
• rsync -av es el cp correcto para directorios: incremental, verificable, reanudable, con --dry-run y con la barra final que sí importa.
• tar empaqueta preservando permisos; se lista con -t antes de extraer y se usa -C para no arrastrar rutas absolutas.
• gzip por defecto, xz para distribuir, zip para Windows, y sabes justificar la elección.
• Y has preparado un paquete de producción completo: verificado, con suma de comprobación y probado antes de enviarlo.

Ya sabes mover archivos de sitio. Falta lo que hay dentro de ellos. En la próxima lección, Visualización y Edición de Archivos, aprenderás a mirar el contenido sin abrir un editor con cat, less, head y tail —incluido tail -F para seguir errores.log en vivo mientras ocurre una incidencia—, y a editarlo con nano a fondo y con el vim de supervivencia que necesitarás el día que entres en un servidor donde no haya otra cosa. Establecerás además una convención que el curso usará a partir de ahí: copia de seguridad del fichero de configuración antes de tocarlo. Y verás cómo comparar dos versiones de app.conf con diff para saber exactamente qué cambió, que es la pregunta que se hace siempre después de que algo deje de funcionar.