bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: history -a misbehaves with $HISTSIZE


From: Айрат Васбикарамов
Subject: Re[2]: history -a misbehaves with $HISTSIZE
Date: Wed, 13 Feb 2019 23:47:59 +0300



>Вторник, 12 февраля 2019, 19:58 +03:00 от Chet Ramey <chet.ramey@case.edu>:
>
>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  chet@case.edu http://tiswww.cwru.edu/~chet/

Thanks for clarification. But I still consider this behavior inconsistent.

1)  Why we need to check that history_lines_this_session is less than 
history_offset? history_lines_this_session always stores number of lines in 
this session. So we can just append this much lines.

2) Let me rewrite what happens in preceding example. We can set $HISTSIZE which 
we prefer (for example in bashrc). Then we start new session. And it's  
happened that we type more than $HISTSIZE commands. Then if I type "history 
-a", I expect that $HISTSIZE commands will be appended to history file (leading 
commands will disappear, as our buffer can't hold this much commands). But 
actually nothing will be added!

3) Actually this behavior already present in code if histappend option is set.
   bashhist.c    maybe_save_shell_history()
    ... 
if (history_lines_this_session <= where_history () || force_append_history)
...
 So if we say to append history at exit it doesn't bother to check that 
history_lines_this_session is less than offset. It just save 
min(history_lines_this_session, HISTSIZE) to history file. So it's not clear 
why when we explicitly tell to append history behavior is "weaker" than when we 
set histappend option.
-- 
Airat Vasbikaramov

reply via email to

[Prev in Thread] Current Thread [Next in Thread]