On 2/5/11 10:49 PM, Michael Witten wrote:
> On Sat, Feb 5, 2011 at 20:09, Jon Seymour <jon.seym...@gmail.com> wrote:
>> I guess the point is that in versions of bash that do store the
>> timestamp in the .bash_history file
>
> To clarify, the timestamp is stored whenever HISTTIMEFORMAT has a
> non-null value; the bash version doesn't particularly matter unless
> you're suggesting that HISTTIMEFORMAT is non-null by default under
> some bash versions.
>
> If there aren't really any concerns about using the same history file
> with older versions of bash, then wouldn't it be better to have a new
> file format that can handle multi-line commands more directly?
The existing format has the advantage of being simple and easy to parse:
each line in the history file is a separate history entry. A new
history file format would have to have some means to differentiate it
from this default, which implies some kind of versioning. Using the
file name (a la ssh's authorize_keys/authorized_keys2 distinction) is
not viable.
Any new format would have to either use some delimiter to note the
beginning and end of the history entry -- using a timestamp which may
or may not be present is not a good option -- or encode newlines in
commands using some other character. Otherwise, you can't tell the
difference between command-oriented history with embedded newlines
and a history file with multi-line commands intentionally stored as one
line per history entry.
In any case, there won't be any new history file format until the
next major bash/readline release, if it happens.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
