El comando rm elimina archivos y directorios del sistema de archivos de forma permanente e inmediata. No hay una papelera de reciclaje en la línea de comandos estándar, no hay confirmación por defecto, y no hay deshacer nativo. Cuando rm termina, los datos han desaparecido desde el punto de vista del usuario: el sistema de archivos libera los bloques y los marca como disponibles para sobrescribir.
Esto funciona así por diseño. Unix nació en entornos donde el almacenamiento era escaso y los operadores sabían lo que hacían. La papelera de reciclaje es una abstracción que los entornos gráficos añadieron décadas después para usuarios que no esperaban consecuencias irreversibles al mover un icono a la basura. La CLI no hace esa suposición sobre ti.
Usas rm siempre que necesites liberar espacio, limpiar artefactos de compilación, eliminar logs viejos o borrar ficheros temporales desde un script. Lo que no deberías usar cuando trabajas con ficheros de los que no estás seguro, o cuando estás escribiendo un path a mano a las 2 de la mañana bajo presión.
Lo que se rompe cuando te equivocas es proporcional al path que escribiste. Un rm archivo.txt mal escrito borra el fichero equivocado. Un rm -rf /ruta/incorrecta/ puede dejar un servidor inoperable en segundos. No hay Ctrl+Z. Los datos pueden ser irrecuperables si los bloques ya se sobrescribieron, cosa que en un sistema activo ocurre rápido.
# Situación real: limpiar artefactos de build en un proyecto # Estructura que tenemos: # proyecto/ # ├── src/ # ├── build/ ← queremos borrar este directorio completo # │ ├── app.o # │ ├── lib.o # │ └── output/ # │ └── app # ├── logs/ # │ ├── debug.log # │ └── error.log ← solo este fichero queremos borrar # └── config.bak ← y este cd ~/proyecto # Borrar un único fichero. Simple, sin opciones. rm logs/error.log # Borrar otro fichero. Igual de directo. rm config.bak # rmdir intenta borrar un directorio — pero solo funciona si está VACÍO. # Si tiene contenido, falla con un error claro. Eso es exactamente lo que # queremos cuando no estamos seguros de lo que hay dentro. rmdir build/output/ # esto fallará porque output/ contiene 'app' # Para borrar un directorio con contenido necesitamos -r (recursivo). # Antes de ejecutarlo, verificamos que el path es exactamente lo que creemos: ls -la build/ # pausa de dos segundos: ¿es esto lo que quiero borrar? rm -r build/ # Si además queremos suprimir errores en caso de que el directorio # ya no exista (útil en scripts de CI que se ejecutan varias veces), # añadimos -f. Pero fíjate: lo usamos con un path muy específico, # nunca con un comodín sin haber verificado antes qué cubre. rm -rf build/ # segunda ejecución: no falla aunque build/ ya no exista # Instalando trash-cli como alternativa más segura para el día a día sudo apt install trash-cli # trash-put mueve a la papelera del sistema (~/.local/share/Trash) # desde donde puedes recuperar con trash-restore o vaciar con trash-empty trash-put logs/debug.log # Ver qué hay en la papelera antes de vaciarlo definitivamente trash-list # Recuperar si te arrepentiste trash-restore # muestra un menú interactivo
rmdir build/output/ falla intencionalmente porque el directorio no está vacío. Ese fallo es información útil, no un obstáculo. rmdir solo borra directorios vacíos: si algo falla, te estás enterando de que había contenido que no habías contabilizado.
La línea ls -la build/ antes del rm -r no es paranoia, es el hábito correcto. Cuando trabajas con -r, estás autorizando que se borre un árbol completo. Dos segundos mirando la salida del ls pueden evitar un incidente.
La diferencia entre rm -r y rm -rf es que -f añade dos comportamientos: silencia errores si el fichero o directorio no existe, y elimina la confirmación en ficheros de solo lectura sin preguntar. En scripts de CI o Makefiles esto es normal y correcto. En la terminal interactiva, úsalo solo cuando sepas exactamente qué cubre el path.
trash-cli funciona con la papelera estándar de freedesktop, la misma que usa GNOME, KDE o Xfce. Si borras algo con trash-put y luego abres el gestor de ficheros gráfico, lo verás en la papelera del escritorio. Son la misma ubicación: ~/.local/share/Trash/. La recuperación con trash-restore es interactiva: lista los ficheros borrados con su path original y te deja elegir cuál restaurar.
El patrón de rm -rf /algo se ha cobrado servidores de producción enteros, generalmente cuando una variable de entorno estaba vacía en un script y el path resultante era / en lugar de /var/app/cache. Antes de usar -rf en un script, verifica que las variables que componen el path no puedan ser vacías. Una guarda sencilla como [[ -n "$DIR" ]] && rm -rf "$DIR" en bash es suficiente para evitar ese escenario.
N° 22