3 ms·
Not sure why you are getting all zeros in your duration column. Should be setopt ExtendedHistory (Zsh setopts, like Nim identifiers, are "style insensitive").
by cb321 6y ago
Not sure why you are getting all zeros in your duration column. Should be setopt ExtendedHistory (Zsh setopts, like Nim identifiers, are "style insensitive").
From the Zsh man page:
EXTENDED_HISTORY <C>
Save each command's beginning timestamp (in seconds since the epoch) and the duration (in seconds) to the history file. The format of this prefixed data is:
`: <beginning time>:<elapsed seconds>;<command>'.
(EDIT: My best guess explanation is some competing/conflicting setopt, but the Zsh mailing list could almost surely help you. Also, `history -fD` may show the correct answer even if the saved file has all 0s.)
- chrisshroba 6y agoThank you! How strange. `history -fD` does work, but only for commands in the current zsh session. It seems durations are being stored in memory but written out as 0's. I'll try the mailing list soon :)
- cb321 6y agoLooks like you probably also have SHARE_HISTORY set? [1] [1] https://unix.stackexchange.com/questions/396809/zsh-share-history-or-inc-append-history-breaks-extended-history https://unix.stackexchange.com/questions/396809/zsh-share-hi...
- jolmg 6y agoIn my case, I have INC_APPEND_HISTORY enabled. It appears I get 0 in the duration column because it's writing to the history file before executing the command. I see there's the alternative option INC_APPEND_HISTORY_TIME to append to history after the command finishes in order to include the duration. It makes sense. It's preferring to add to history immediately so that it's available to other shells without having to wait for the command to finish. From the manpage: > INC_APPEND_HISTORY_TIME This option is a variant of INC_APPEND_HISTORY in which, where possible, the history entry is written out to the file after the command is finished, so that the time taken by the command is recorded correctly in the history file in EXTENDED_HISTORY for‐ mat. This means that the history entry will not be available immediately from other instances of the shell that are using the same history file. This option is only useful if INC_APPEND_HISTORY and SHARE_HISTORY are turned off. The three options should be considered mutually exclusive.
- cb321 6y agoHah. @jolmg & I almost collided to the second. :-) That stackexchange link had an answer with the INC_APPEND_HISTORY_TIME setopt which seems to work without SHARE_HISTORY (I think using his whole stackexchange answer might still result in 0s..at least it did for me when I ran it in a precmd() instead of adding the hook, but it could always be something else varying between his & my setopts).
- cb321 6y agoRead this thread [1] at the Zsh mailing list to the end. It looks like either share_history or inc_append_history break recording duration in a fundamental way. The TL;DR is that the history line is written out before the command in question completes. I guess the thinking is that inc/shared history with some very long running command is not as useful if you wait until it ends and you have elapsed time data to append that line. I feel like that might be a personal issue - like if you almost only ever run commands 1-90 seconds then you are fine with the delay. Anyway, this also explains why it is available from the `history -fD` command but not in the file. [1] https://www.zsh.org/mla/workers/2011/msg01297.html https://www.zsh.org/mla/workers/2011/msg01297.html