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 c...@case.edu http://tiswww.cwru.edu/~chet/
*** ../bash-5.0-patched/bashhist.c 2018-07-05 22:41:14.000000000 -0400
--- bashhist.c 2019-02-23 17:12:02.000000000 -0500
***************
*** 437,445 ****
char *filename;
{
! int fd, result;
struct stat buf;
result = EXECUTION_SUCCESS;
! if (history_lines_this_session > 0 && (history_lines_this_session <=
where_history ()))
{
/* If the filename was supplied, then create it if necessary. */
--- 437,445 ----
char *filename;
{
! int fd, result, histlen;
struct stat buf;
result = EXECUTION_SUCCESS;
! if (history_lines_this_session > 0)
{
/* If the filename was supplied, then create it if necessary. */
***************
*** 454,457 ****
--- 454,461 ----
close (fd);
}
+ /* cap the number of lines we write at the length of the history list */
+ histlen = where_history ();
+ if (histlen > 0 && history_lines_this_session > histlen)
+ history_lines_this_session = histlen; /* reset below anyway */
result = append_history (history_lines_this_session, filename);
/* Pretend we already read these lines from the file because we just
