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

[Айрат Васбикарамов]

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

Yes, that's what I mean.

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

I don't think that happens frequent either. But it's possible. Someone set 
HISTSIZE to 1000 as he don't care about too old commands and it's happened that 
he typed more than 1000 command. Then he run "history -a" to synchronize 
current history with another started bash for example. And lost recent 
commands. Possibly he notice it. But may not.

Anyway I don't see downsides of this behavior comparing to current. And it 
seems more intuitive to me. So should it be default?

>Воскресенье, 24 февраля 2019, 1:16 +03:00 от Chet Ramey <chet.ramey@case.edu>:
>
>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.
>
>Chet
>
>-- 
>``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/


-- 
Airat