Re: In response to the maximum size of $HISTSIZE

[Francisco Borges <f.borges@xxxxxx>]

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

> On 4/10/06, Francisco Borges <f.borges@xxxxxx> 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