On Wed, Aug 31, 2011 at 04:41:07PM -0400, Geoff Steckel wrote: > On 08/31/2011 03:42 PM, Marco Peereboom wrote: > >Version 4 fixes all reported bugs. > > > >Some folks have expressed doubt about the simplistic way of updating the > >history file. Specifically the rewriting of all entries. I am > >sensitive to that and know a couple of optimizations that can easily be > >applied. However before I go there I'd like to get a thumbs up or down > >on this approach. It trashes the binary history file format and > >replaces it with flat text. Is this something we want? > IMnsHO, external non-text files have serious maintenance problems > including version dependency. Does the external binary file have any > significant advantages over flat text? If not, my experience is that > flat text is 99+% a better choice for maintainability, > interchangeability, and general obviousness. > > If an internal binary format has significant advantages, is the cost > of conversion significant (coding time and execution time?) If not, > go with an external text format for the above reasons.
It has one benefit in the ksh case. It retains the line number; the flat text file obviously can't do that without introducing side effects. Now I don't know why having persistent line numbers is useful but that aside. Oh, and it gets corrupted from time to time and one does not have a chance of (without writing some code) of recovering some or any of it. I tend to lose a history file every month or so. > Pure appends have a stylistic appeal as well. > > Anecdotally, almost no-one has been able to show me real-world > efficiency gains from binary files for applications where a text > file works, especially for ones read once and/or written once per > program invocation. > > geoff steckel > gwes at oat mumble com
