On 2/10/19 4:59 PM, Айрат Васбикарамов wrote:
> Machine Type: x86_64-unknown-linux-gnu
> Bash Version: 4.4
> Patch Level: 23
> Release Status: release
> Description:
> $ history -c
> $ HISTSIZE=2
> $ HISTFILE=$(mktemp)
> $ history -a
> $ cat $HISTFILE
> $
> File is still empty!
> bashhist.c:maybe_append_history():
> if (history_lines_this_session > 0 && (history_lines_this_session <=
> where_history ()))
> It seems like history_lines_this_session don't affected by HISTSIZE and it's
> value 3. But where_history() returns 2.
OK, let's look at what happens. The purpose of the -a option is to append
new history entries, those not read from the history file and entered in
this shell session, to the history file. The goal is to avoid duplicates.
The history_lines_this_session is self-explanatory. How many history
entries have we seen since this shell session initialized the history
list? Since it represents the number of entries in the history list
that are new with this shell session, it gets reset to 0 when you clear
out the history list with `-c'.
Now, how do you determine how many entries in the history list were
read from the history file? Well, you make the assumption that if the
current offset in the history list is greater than the number of entries
entered in the current shell session, you must have some entries there
that were read from the history file, and you can go ahead and append the
last history_lines_this_session entries to the history file.
You can obviously fool this by modifying HISTSIZE and violating the
assumption that there is a relationship between the size of the history
list and the original number of lines read from the history file.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
