Un usuario avanzado de Zsh documenta una investigación de varios años sobre un bug que provocaba la pérdida periódica de entradas en el archivo ~/.zsh_history: comandos que sabía que había ejecutado desaparecían sin dejar rastro de corrupción visible. El artículo describe paso a paso la metodología de diagnóstico empleada hasta dar con la causa raíz y conseguir que los desarrolladores publicaran una corrección.
El autor parte de una configuración de Zsh con HISTSIZE=4000, SAVEHIST=10000000 y las opciones INC_APPEND_HISTORY (sin SHARE_HISTORY), de modo que cada sesión escribe de forma independiente en un historial compartido. Para identificar quién truncaba el archivo probó varias herramientas de monitorización del sistema de archivos en Linux: inotifywait (que reveló el patrón de reescritura atómica: lectura del archivo viejo, escritura de uno nuevo y rename), fatrace (que aportó el PID del proceso responsable), strace y, finalmente, bpftrace, con el que obtuvo trazas de pila en cada llamada open(2) sobre ~/.zsh_history.
La pista definitiva llegó al instrumentar Zsh para que abortara de forma ruidosa y analizarse el core dump resultante. El fallo ya está corregido en Zsh 5.9.2 (publicada el 12 de julio de 2026). El texto resulta útil como tutorial de diagnóstico en sistemas Linux con herramientas de tracing (inotify, fanotify, fatrace, strace, bpftrace) y como caso real de ingeniería inversa de un bug intermitente en software de línea de comandos.
