Re: [PATCH] EXTENDED_HISTORY documentation typo

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 27,  9:13pm, Mikael Magnusson wrote:
} Subject: Re: [PATCH] EXTENDED_HISTORY documentation typo
}
} On 27 October 2011 20:50, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > On Oct 27,  6:12pm, Mikael Magnusson wrote:
} > }
} > }     5  18:06  0:00  setopt incappendhistory
} > }     6  18:06  0:00  cat /tmp/test
} > }     7  18:06  0:00  setopt extendedhistory
} > }     8  18:06  0:00  cat /tmp/test
} > }     9  18:06  0:05  sleep 5
} > }    10  18:07  0:00  cat /tmp/test
} 
} Hm? I ran the sleep after I did setopt extendedhistory. Note also that
} the time delta 0:05 is output by history -dD but isn't stored in the
} history file. You didn't quote the histfile excerpt:
} 
} setopt extendedhistory
} : 1319731616:0;cat /tmp/test
} : 1319731618:0;sleep 5
} : 1319731624:0;cat /tmp/test

Ah, I see.  You've found a conflicting feature -- I can't call it a bug
-- with INC_APPEND_HISTORY (which will also affect SHARE_HISTORY).

The history entry is written out in hend() as soon as the command
line is accepted for execution, but the elapsed time isn't (clearly
cannot be) recorded until the call to hbegin() after the command has
finished.  The HISTFILE is never re-written when it's being appended
on the fly, so there is no opportunity for the elapsed time to be
updated.

Particularly with respect to SHARE_HISTORY there's really no way to
fix this -- to be useful, the history has to be shared before the
elapsed time is known.  Since SHARE and INC_APPEND are handled in
the same code, I'm reluctant to suggest that we attempt to change
this behavior.

The same thing happens when the shell exits because of an "exec":
There's no hbegin() call after that final command, so the elapsed
time is never logged.

: 1319811645:3;sleep 3
: 1319811651:0;exec sleep 9

This should at least be documented.  In fact it's even slightly
worse (?) than what I just described -- if the file happens to be
locked at the instant the append is attempted, zsh simply skips
the operation for speed/responsiveness and writes all entries after
the *next* command finishes (or the shell exits).  In that case the
duration of any command whose write was postponed will in fact be
recorded.  The upshot is that the elapsed time is unreliable if the
INC_APPEND_HISTORY or SHARE_HISTORY options are set.

(I was wrong about order dependence on setopt extendedhistory; the
shell DOES record the elapsed time even when not saving it.  I'm
surprised no one corrected me on that.)

There's one further thing pursuant to another thread:  If you setopt
INC_APPEND_HISTORY, then the history file does get updated on the
fly even though NO_RCS may prevent it being written at shell exit.
There are, obviously, an incredible number of these obscure setopt
interactions that it's very difficult to track and document.