Re: In response to the maximum size of $HISTSIZE

Re: In response to the maximum size of $HISTSIZE

[Francisco Borges]

» On Mon, Apr 10, 2006 at 06:06PM +0200, Nikolai Weibull wrote:

> On 4/10/06, Francisco Borges <f.borges@rug.nl> wrote:
> > » On Mon, Apr 10, 2006 at 04:10PM +0200, Nikolai Weibull wrote:
> >
> > What happens with mistakes setting date? What happens when you go on
> > vacantion? Abandon the account for a while?
>
> So you lose the history that isn't interesting any more.  I really
> don't see what you're getting at.  Choose and mix the settings as you

I'm pointing out possible failure points, so that you can explain how do
you expect this variable to interact with HISTSIZE... Like, which would
have precedence when both are set? Would they be aware of each other or
simply ignore the other variable setting?

> like.  What is wrong with being able to cap the age of the history
> entries?

Nothing.

I just don't see any need for it and I just pointed that, for the usage
I envisioned for time-based history control, it could (sort of) be
easily achieved using logrotate.

> > You could then happily grep (or zgrep) on it. Which is not the same as
> > zsh's history searching power, but how often do you need to retrieve a 2
> > or 3 year old command?
>
> That's the same thing as saying HISTSIZE should be capped as well, as

No, it's not the same thing.

> it will fill up with two- or three-year-old commands if you set it to
> a high enough value.

The suggestion I sent you can be easily changed not to delete logfiles
at all, putting no limit on them. As I pointed out in first email, it
gets you time-pattern controlled shell command memory, which is what you
seem to be looking for. But it can only be a solution, again as I
already pointed out, *IF* you don't care about using grep to find
history entries, and not zsh tools.

All of that was assuming you meant to have time control longer than that
given by normal HISTSIZE and not shorter...

-- 
Francisco Borges

Re: In response to the maximum size of $HISTSIZE

[Nikolai Weibull]

On 4/10/06, Francisco Borges <f.borges@rug.nl> wrote:
> » On Mon, Apr 10, 2006 at 04:10PM +0200, Nikolai Weibull wrote:
>
> > Why not make it possible to have a time-based history-scheme instead
> > of a static size-based one?  What I mean is that since Zsh allows
> > history items to be timestamped, add another parameter $HISTAGE and
> > keep items "younger" than that value.  It could be given in days,
> > weeks, months and/or years, I suppose.

> What happens with mistakes setting date? What happens when you go on
> vacantion? Abandon the account for a while?

So you lose the history that isn't interesting any more.  I really
don't see what you're getting at.  Choose and mix the settings as you
like.  What is wrong with being able to cap the age of the history
entries?

> You could then happily grep (or zgrep) on it. Which is not the same as
> zsh's history searching power, but how often do you need to retrieve a 2
> or 3 year old command?

That's the same thing as saying HISTSIZE should be capped as well, as
it will fill up with two- or three-year-old commands if you set it to
a high enough value.

  nikolai

Re: In response to the maximum size of $HISTSIZE

[Francisco Borges]

» On Mon, Apr 10, 2006 at 04:10PM +0200, Nikolai Weibull wrote:

> Why not make it possible to have a time-based history-scheme instead
> of a static size-based one?  What I mean is that since Zsh allows
> history items to be timestamped, add another parameter $HISTAGE and
> keep items "younger" than that value.  It could be given in days,
> weeks, months and/or years, I suppose.

What happens with mistakes setting date? What happens when you go on
vacantion? Abandon the account for a while?

I would rather have the shell appending all entries removed due to
HISTSIZE into some other file.

Anyway what you want to have is to configure logrotate and run it on
cron. logrotate can handle this easily and be tailored to the task,
something like this should work (untested!):

cronjob:
@daily	cat .zhistory >>! .zhistory.log
@daily 	logrotate ~/rotate_hist.rc

# Logrotate UNTESTED conf file

$HOME/.zhistory.log {
           monthly
	   # weekly
           # daily
           rotate 36
	   dateext
	   nomail
	   create
#	   firstaction
#	   # you may remove duplicates here....
#	   endscript
       }
# END of it.

You could then happily grep (or zgrep) on it. Which is not the same as
zsh's history searching power, but how often do you need to retrieve a 2
or 3 year old command?

Cheers,
-- 
Francisco Borges

In response to the maximum size of $HISTSIZE

[Nikolai Weibull]

Why not make it possible to have a time-based history-scheme instead
of a static size-based one?  What I mean is that since Zsh allows
history items to be timestamped, add another parameter $HISTAGE and
keep items "younger" than that value.  It could be given in days,
weeks, months and/or years, I suppose.

  nikolai