logoalt Hacker News

Tracking down a Zsh history data loss bug

69 pointsby ingveyesterday at 9:39 PM23 commentsview on HN

Comments

pratyahavatoday at 6:26 AM

this is an example of overcomplicated solutions that could be avoided with the tool we already have for years - file system - why do this "heroic" effort of "cleverly" putting everything in one file from many sessions if we could just write command history of every session into a new separate file in a directory and read all history files from the dir instead of reading one file.

show 1 reply
mmh0000yesterday at 11:26 PM

I have nearly a decade of zsh history. Reading that article I came to the conclusion that I may have been hit by that bug in the past but I haven’t noticed.

Then I kept reading and the author mentions accidentally exporting HISTFILE[1] and I screamed in terror and ran to my computer as I realized a mistake I’ve been making for…ever.

I am now both happy and sad I read this article.

[1] https://github.com/stapelberg/configfiles/commit/32dcda0f49a...

show 1 reply
chillpenguintoday at 3:38 AM

I ran into this a few years ago (or I ran into a very similar bug). I started backing up my history file regularly because it was so annoying to lose all that history. I'll keep backing it up, but this fix is appreciated!

nubinetworktoday at 3:22 AM

That's a bug? Happens to me with bash all the time, all I have to do is open 2 terminals at the same time... whichever one I close last is the one that writes its history. /shrug

show 2 replies
aclindsayesterday at 11:17 PM

Nice work! I have felt like I lost zsh history before but never looked into it.

myshapeprotocoltoday at 2:06 AM

Tracking down subtle data loss edge cases in shell history internals requires absolute precision. Great debugging write-up.

TZubiriyesterday at 11:57 PM

Does zsh have that 2000 command limit by default?

You can't expect much from a system that has those defaults, I'm all for traditions, but if I were to depend on a system for command history, it wouldn't be anything that reads a bash_history, a revolution is needed, not incremental optimizations

P.s: what I do is set it to unlimited on both size and line count, but it's not a forensic grade audit trace, we'd need an OS, or ssh command logger, preferably one that writes to an external disk, but it can be to a root controlled file, definitely not to a user owned file.

Security protects not only against attackers, but against bugs, a user's command history should not be deletable by user. Anything else is a wrong architecture that we are just carrying by inertia and laziness.

show 1 reply
kevinbaivyesterday at 11:30 PM

[dead]

fragmedetoday at 1:10 AM

Are people not just using http://atuin.sh these days?

show 4 replies