What was the reason for history -D not reporting runtimes?

What was the reason for history -D not reporting runtimes?

[Nikolai Weibull]

I have a vague memory of asking this question earlier, but I couldn't
find it in any of the archives and not in my own mail-archive either,
so here it goes (again, probably):

Why does history -D not report times correctly, only giving 0:00?

It has something to do with some setting that interferes with the
recording of this information, but I don't remember precisely which
setting it was.

Thanks.

  nikolai

Re: What was the reason for history -D not reporting runtimes?

[Nikolai Weibull]

On 11/25/06, Matt Wozniski <godlygeek@gmail.com> wrote:
> To record that information, you need "setopt ExtendedHistory".  See
> http://zsh.sunsite.dk/Guide/zshguide02.html#l18 (Thanks, PWS!)

Yes, but that I already have.  The -D information somehow isn't
recorded.  I thought it was incappendhistory that caused this, but I
don't have that set.

  nikolai

Re: What was the reason for history -D not reporting runtimes?

[Wayne Davison]

On Sat, Nov 25, 2006 at 06:52:50PM +0100, Nikolai Weibull wrote:
> Yes, but that I already have.  The -D information somehow isn't
> recorded.  I thought it was incappendhistory that caused this, but I
> don't have that set.

The SHARE_HISTORY option also causes this.  This is because the current
algorithm for sharing history writes out the history lines as soon as
you enter the command.  Perhaps we should revisit the reasons for this
design choice to see if we still agree that this is the best spot to do
the shared/inc-append history updating.

..wayne..

Re: What was the reason for history -D not reporting runtimes?

[Nikolai Weibull]

On 11/27/06, Wayne Davison <wayned@users.sourceforge.net> wrote:
> On Sat, Nov 25, 2006 at 06:52:50PM +0100, Nikolai Weibull wrote:
> > Yes, but that I already have.  The -D information somehow isn't
> > recorded.  I thought it was incappendhistory that caused this, but I
> > don't have that set.
>
> The SHARE_HISTORY option also causes this.  This is because the current
> algorithm for sharing history writes out the history lines as soon as
> you enter the command.  Perhaps we should revisit the reasons for this
> design choice to see if we still agree that this is the best spot to do
> the shared/inc-append history updating.

I don't have that set either.  dang...

setopt autocd                                 \
       autopushd                              \
       completeinword nolistambiguous         \
       rcexpandparam rcquotes                 \
       correct dvorak                         \
       nonotify                               \
       nobeep

That's what I set.  I do have some zstyles for history completion:

zstyle ':completion:*:history-words' stop yes
zstyle ':completion:*:history-words' remove-all-dups yes
zstyle ':completion:*:history-words' list no
zstyle ':completion:*:history-words' menu yes

but I don't see how that can affect anything.

  nikolai

Re: What was the reason for history -D not reporting runtimes?

[Nikolai Weibull]

On 11/27/06, Nikolai Weibull <now@bitwi.se> wrote:
> On 11/27/06, Wayne Davison <wayned@users.sourceforge.net> wrote:
> > On Sat, Nov 25, 2006 at 06:52:50PM +0100, Nikolai Weibull wrote:
> > > Yes, but that I already have.  The -D information somehow isn't
> > > recorded.  I thought it was incappendhistory that caused this, but I
> > > don't have that set.
> >
> > The SHARE_HISTORY option also causes this.  This is because the current
> > algorithm for sharing history writes out the history lines as soon as
> > you enter the command.  Perhaps we should revisit the reasons for this
> > design choice to see if we still agree that this is the best spot to do
> > the shared/inc-append history updating.
>
> I don't have that set either.  dang...
>
> setopt autocd                                 \
>        autopushd                              \
>        completeinword nolistambiguous         \
>        rcexpandparam rcquotes                 \
>        correct dvorak                         \
>        nonotify                               \
>        nobeep


Oh boy.  Turns out extendedhistory wasn't on by default like I
thought.  Anyway, even with it set it doesn't work.  Can appendhistory
mess it up?

Also, why isn't histsavebycopy set by default, as the documentation
suggests that it be set unless you have special needs?

  nikolai

Re: What was the reason for history -D not reporting runtimes?

[Bart Schaefer]

On Nov 27,  8:47am, Nikolai Weibull wrote:
}
} Oh boy.  Turns out extendedhistory wasn't on by default like I
} thought.  Anyway, even with it set it doesn't work.  Can appendhistory
} mess it up?
} 
} Also, why isn't histsavebycopy set by default, as the documentation
} suggests that it be set unless you have special needs?

Neither of these is set by default because historically (no pun) zsh and
other shells could [theoretically] all use the same history file. The two
options you mention would break backwards compatibility if they were set.

In almost every case of "why doesn't zsh do this fancy thing by default?"
the answer is "because people have been using zsh since about 1990 and we
don't want to unexpectedly break anyone's configuration on upgrade."

Yeah, I know, nowadays other software routinely breaks everything about a
past installation when you upgrade it, or at least requires you to go
through some kind of automated conversion process from which there is no
safe return short of restoring from a backup.  That doesn't mean I like
it when it happens.

Re: What was the reason for history -D not reporting runtimes?

[Wayne Davison]

On Mon, Nov 27, 2006 at 05:46:25PM +0100, Nikolai Weibull wrote:
> Also, why isn't histsavebycopy set by default, as the documentation
> suggests that it be set unless you have special needs?

It is set by default in a zsh that supports the option.  If I run
"unsetopt | fgrep copy", I see "nohistsavebycopy", which means that
the option is enabled (i.e. that "unsetopt nohistsavebycopy" is what
is currently in effect, and thus the double-negation of that command,
"setopt histsavebycopy", is also in effect).

..wayne..

Re: What was the reason for history -D not reporting runtimes?

[Nikolai Weibull]

On 11/24/06, Nikolai Weibull <now@bitwi.se> wrote:
> I have a vague memory of asking this question earlier, but I couldn't
> find it in any of the archives and not in my own mail-archive either,
> so here it goes (again, probably):
>
> Why does history -D not report times correctly, only giving 0:00?

Ah, I found the culprit.  I use Bart's version of preexec for setting
the title inside screen.  It seems that using the z expansion flag in
cmd=${(z)1}) messes up the time-tracking code somehow.

This is what I have

_set_title () {
  [[ $LOCKTITLE == 1 ]] && return
  case $TERM in
    (screen*)
      print -nR $'\ek'${1[1,18]}$'\e\\' ;;
  esac
  return 0
}

precmd () {
  _set_title zsh
}

preexec () {
  local -a cmd

  cmd=(${(z)1})
  case $cmd[1] in
    (fg)
      if (( $#cmd == 1 )); then
        cmd=(builtin jobs -l %+)
      else
        cmd=(builtin jobs -l ${(Q)cmd[2]})
      fi ;;
    (r)
      cmd=($(builtin history -n -1))
      _set_title $cmd[1]:t
      return ;;
    (%*)
      cmd=(builtin jobs -l ${(Q)cmd[1]}) ;;
    (exec)
      shift cmd ;&
    (*)
      _set_title $cmd[1]:t
      return ;;
  esac

  local -A jt

  jt=(${(kv)jobtexts})

  $cmd >>(read num rest
          cmd=(${(z)${(e):-\$jt$num}})
          _set_title $cmd[1]:t) 2>/dev/null
}

I'm unable to determine why this breaks.  If I substitute ${=1} for
the expansion, it still breaks as soon as it gets to printing in
_set_title.

  nikolai