[Top][All Lists]

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

Re: history -a misbehaves with $HISTSIZE

From: Chet Ramey
Subject: Re: history -a misbehaves with $HISTSIZE
Date: Sat, 23 Feb 2019 17:16:45 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 2/13/19 3:47 PM, Айрат Васбикарамов wrote:

Sorry it took a while to respond; this message ended up in my spam folder
for some reason.

> 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.

If you're at the end of the history, history_offset is the index of the
last entry in the history list. You can't just append
history_lines_this_session; there aren't that many entries in the history
list. You don't really have to worry about this; append_history already
takes care of it.

> 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!

OK. So in this case, it doesn't append anything. I think it violates one of
the assumptions in place when the code was written (1990!). The interesting
thing is that if you type only one more command before running `history -a'
again, it will "work", since maybe_append_history() resets the value of
history_lines_this_session to 0 no matter what.

I don't think this would happen too much in practice, though, because if
you wait until you have more than $HISTSIZE history entries, you'll lose
information no matter what you use.

It seems like what you want is min(history_lines_this_session, history_offset),
kind of like what you say below. Try the attached patch and see if it
does what you want.

> 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.

The `histappend' option explicitly doesn't care about duplicates, so it
never cared about trying to figure out the history entries that hadn't
been 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    address@hidden    http://tiswww.cwru.edu/~chet/

Attachment: history-append.patch
Description: Text document

reply via email to

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