Local history

Local history

[Peter Stephenson]

I'm still thinking about a way of getting a local command history.  My
particular use is so that zcalc and similar functions can keep their own
data, separate from the main command history.

The first thing I tried was manipulating HISTFILE inside the function and
using fc -R and fc -W.  But this doesn't work too well because the history
list at the start contains lots of irrelevant bits.  Maybe there's a way of
truncating the internal list after saving one list and before loading the
other, but at this point I start to wonder whether I should be doing
something different.  In particular, incremental appending and history
sharing will make things well confused.

Does anyone have any experience of or feeling for this?  I can see various
possible ways of proceeding, most (given my experience so far) involving
internal alterations.  However, the fourth possibility is quite attractive.

- Tidy up the mechanism in hist.c to make it easier to swap histories.
Needs some way of doing this for both the internal history and external
files, since Wayne has gone to some lengths to make them consistent.  This
sounds quite nasty to me.

- Abstract the interface in hist.c.  Make it support both the current
file-based mechanism for accessing the history and a mechanism tied to
arrays.  The alternative mechanism can be simpler, since the functions that
use it can do reading, writing or appending where necessary.

- Add an additional array-based system inside zle, so that we don't use
hist.c at all in this case.  There are two parts to this:  adapt
zle_history.c for the alternative system, and adapt bin_vared() to put
the text into this history.  (`Array-based' could mean two things:  we
input values as an array and export them to an array on entry or exit to
the function, or to vared itself, or we tie the entries in the array
directly to the history list seen inside zle.)

- Write a completely separate history mechanism based on zle widgets.
Rebind the keys when using vared.  Hence `vared-up-line-or-history' would
temporarily replace `up-line-or-history' and look in the array for the
previous entry.  If zle turns out not to be up to it, we can probably add
the necessary functions; they may be of more general use than just history.
We can supply this system in Functions/Zle.  Unfortunately we have to
rewrite the various search functions from scratch, too.

- Or maybe I'm being faint-hearted and mainpulating the history parameters
and fc will do the trick after all.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Local history

[Oliver Kiddle]

Peter Stephenson wrote:
> 
> I'm still thinking about a way of getting a local command history.  My

> Does anyone have any experience of or feeling for this?

I don't have any suitable "experience of" but my feeling is that rather
than having separate mechanisms for making different things local
(traps, history, functions, options etc), it would be better if all
these things were available as parameters. Syntactically there then only
needs to be one way to manipulate these structures from the shell. The
syntax here might be just `local .sh.history'. I said something to this
effect on the shell list a while back in reference to local traps.

For these structures (history etc) to be implemented efficiently as
parameters compound variables would help but we might get round it by
just using special types. For some things it would just amount to things
in zsh/parameter being the real data.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: Local history

[Danek Duvall]

Is this related to the problem I'm having with the following function:

    edh() {
    	local histfile

	histfile=${HISTFILE:-$HOME/.zshist}

	fc -AI $histfile
	vi + $histfile
	fc -R $histfile
    }

The idea is to sync the current history to a file, edit it, and read it
back in.  It used to work back in the 3.1.9 days (I submitted it to the
(users?) list when someone requested similar functionality), but it
broke sometime since.

My normal course is to delete the last few lines of the history.  And
while they disappear from the end of the history, they reappear at the
beginning.  Re-running the function -- where those lines don't appear in
the editor at all -- makes them disappear entirely.

What's never worked is to do the sync to some arbitrary file, though I
don't remember the symptoms of that.

Danek

Re: Local history

[Wischnowsky, Sven]

Peter wrote:

> I'm still thinking about a way of getting a local command history.  My
> particular use is so that zcalc and similar functions can 
> keep their own
> data, separate from the main command history.

[Not only does it break lines automatically, it also can't do that right...]

I've been wishing for that, too, when I wrote the nslookup function. Bart
came up with a solution using only fc and the parameters. but unfortunately
that changed the numbers in the currently used history -- not really usable.

I was thinking about doing it only at the very core, namely supporting more
than one history list and a way (option to fc or something) to switch between
these lists. One could then give them names and use $HISTFILE as the prefix
of the filenames for the different histories (or support per-list flags
saying if they are to be saved at all).

That `sounded' not too complicated but I admit that I didn't really look into
it. Maybe it's harder now with all this new history stuff I've not looked at
yet.

Bye
  Sven

--
Sven wischnowsky                            wischnow@berkom.de

Re: Local history

[Bart Schaefer]

On Nov 16,  5:27pm, Peter Stephenson wrote:
}
} I'm still thinking about a way of getting a local command history.  My
} particular use is so that zcalc and similar functions can keep their own
} data, separate from the main command history.

It would be nice if the vared builtin could do the same, though that has
some problems: `vared -h' would have to switch from the vared history to
the command history, and probably also disable saving the vared history.
 
} The first thing I tried was manipulating HISTFILE inside the function and
} using fc -R and fc -W.  But this doesn't work too well because the history
} list at the start contains lots of irrelevant bits.  Maybe there's a way of
} truncating the internal list after saving one list and before loading the
} other, but at this point I start to wonder whether I should be doing
} something different.  In particular, incremental appending and history
} sharing will make things well confused.

As Sven mentioned, I've done this before.  The basic trick is that HISTSIZE
truncates the history as soon as you assign to it, so the technique goes
like this:

	local temphist=${TMPPREFIX}hist SAVEHIST=$HISTSIZE
	HISTFILE=$temphist
	fc -W				# Save internal history
	local HISTSIZE=0		# Truncate internal history
	HISTSIZE=$SAVEHIST
	HISTFILE=~/.zcalc-history
	fc -R				# Read previous zcalc history
	# do zcalc stuff ...
	fc -W				# Save zcalc history
	HISTFILE=$temphist
	fc -R				# Reload old history

Then you have to put in the appropriate traps so the old history gets put
back even if the function is interrupted, etc.

On Nov 16, 10:01am, Danek Duvall wrote:
}
} Is this related to the problem I'm having with the following function:

No, it's not really related.

} My normal course is to delete the last few lines of the history.  And
} while they disappear from the end of the history, they reappear at the
} beginning.  Re-running the function -- where those lines don't appear in
} the editor at all -- makes them disappear entirely.

You've probably set the HIST_EXPIRE_DUPS_FIRST option.  When the file is
read back in, everything in it is a duplicate.  So all the existing lines
get expired, except the deleted ones, with the effect that what you wanted
deleted instead gets moved to the top.

Try adding `setopt localoptions no_histexpiredupsfirst' to the function
and see whether that doesn't get back the behavior you wanted.

On Nov 19,  9:40am, Wischnowsky, Sven wrote:
}
} I was thinking about doing it only at the very core, namely supporting
} more than one history list and a way (option to fc or something) to
} switch between these lists.  One could then give them names and use
} $HISTFILE as the prefix of the filenames for the different histories
} (or support per-list flags saying if they are to be saved at all).

This is, approximately, what savehistfile() does at the very end.  Look
for the variable names starting with `remember_'.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Local history

[Peter Stephenson]

Bart Schaefer wrote:
> As Sven mentioned, I've done this before.  The basic trick is that HISTSIZE
> truncates the history as soon as you assign to it, so the technique goes
> like this:
> 
> 	local temphist=${TMPPREFIX}hist SAVEHIST=$HISTSIZE
> 	HISTFILE=$temphist
> 	fc -W				# Save internal history
> 	local HISTSIZE=0		# Truncate internal history
> 	HISTSIZE=$SAVEHIST
> 	HISTFILE=~/.zcalc-history
> 	fc -R				# Read previous zcalc history
> 	# do zcalc stuff ...
> 	fc -W				# Save zcalc history
> 	HISTFILE=$temphist
> 	fc -R				# Reload old history

That should obviously restore the original HISTFILE at the second last
line.

I adapted this into the following, and it's mostly working fine.  However,
every time it saves back to ~/.zcalc_history, it adds two lines from the
old history at the start which I can't seem to get rid of.  Possibly
trimming SAVEHIST to the actual number of lines to save might work.

Index: Functions/Misc/zcalc
===================================================================
RCS file: /cvsroot/zsh/zsh/Functions/Misc/zcalc,v
retrieving revision 1.5
diff -u -r1.5 zcalc
--- Functions/Misc/zcalc	2001/11/15 18:42:33	1.5
+++ Functions/Misc/zcalc	2001/11/19 17:27:44
@@ -88,6 +88,25 @@
 emulate -L zsh
 setopt extendedglob
 
+# can't be local since required in EXIT trap
+zcalc_orighist=$HISTFILE 
+local temphist=${TMPPREFIX}hist SAVEHIST=$HISTSIZE
+HISTFILE=$temphist
+fc -W
+
+local HISTSIZE=0
+HISTSIZE=$SAVEHIST
+HISTFILE=~/.zcalc_history
+[[ -f $HISTFILE ]] && fc -R
+
+zcalc_restore() {
+    unfunction zcalc_restore
+    fc -W
+    HISTFILE=$zcalc_orighist
+    fc -R
+}
+trap zcalc_restore HUP INT QUIT EXIT
+
 local line latest base defbase match mbegin mend psvar optlist opt arg
 integer num
 
-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Local history

[Bart Schaefer]

On Nov 19,  5:36pm, Peter Stephenson wrote:
} Subject: Re: Local history
}
} Bart Schaefer wrote:
} > 
} > 	local temphist=${TMPPREFIX}hist SAVEHIST=$HISTSIZE
} > 	HISTFILE=$temphist
} > 	fc -W				# Save internal history
} > 	local HISTSIZE=0		# Truncate internal history
} > 	HISTSIZE=$SAVEHIST
} > 	HISTFILE=~/.zcalc-history
} > 	fc -R				# Read previous zcalc history
} > 	# do zcalc stuff ...
} > 	fc -W				# Save zcalc history
} > 	HISTFILE=$temphist
} > 	fc -R				# Reload old history
} 
} That should obviously restore the original HISTFILE at the second last
} line.

Oops, well, yes, what's missing is that the second line should be

	local HISTFILE=$temphist

Originally I had that in the first `local', but then I decided to stuff
the name of the temp file into it's own variable rather than repeat it
twice, and then forgot to localize the assignment on the second line.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: history editing

[Danek Duvall]

On Mon, Nov 19, 2001 at 04:48:24PM +0000, Bart Schaefer wrote:

> On Nov 16, 10:01am, Danek Duvall wrote:
>
> } Is this related to the problem I'm having with the following function:
> 
> No, it's not really related.

Then it gets its own subject.  :)

> You've probably set the HIST_EXPIRE_DUPS_FIRST option.

Nope.

> Try adding `setopt localoptions no_histexpiredupsfirst' to the function
> and see whether that doesn't get back the behavior you wanted.

But I tried this anyway, and it doesn't help.  Anything else I should try?

Thanks,
Danek

Re: history editing

[Wayne Davison]

On Fri, 16 Nov 2001, Danek Duvall wrote:
> My normal course is to delete the last few lines of the history.  And
> while they disappear from the end of the history, they reappear at the
> beginning.  Re-running the function -- where those lines don't appear in
> the editor at all -- makes them disappear entirely.

This seems like the proper thing for your cited function to do.  I'm
assuming you have SAVEHIST and HISTSIZE set to the same value, right?
To see how this works, assume that this value is 100.  You edit the file
down to 97 lines by removing the last 3 lines and then load the history
file.  This pushes the 97 lines onto the history, and the first 3 still
remain up at the top.  If you repeat the sequence, they get pushed off
into oblivion by the re-reading of the same 97 lines.

So, there's nothing wrong with how your function works that I can see.
You could change it to discard the old history if you wanted to, though:

edh() {
    local histfile histsize

    histfile=${HISTFILE:-$HOME/.zshist}
    histsize=$HISTSIZE

    fc -AI $histfile
    vi + $histfile
    HISTSIZE=0
    HISTSIZE=$histsize
    fc -R $histfile
}

..wayne..

Re: history editing

[Danek Duvall]

On Wed, Nov 21, 2001 at 02:21:33PM -0800, Wayne Davison wrote:

> This pushes the 97 lines onto the history,

I think this was the key I was missing.  fc -R doesn't replace the
current history with what it reads in, it adds it to the end.

Setting HISTSIZE to 0 and back seems to work.

I'm surprised, then, that this ever worked.

Thanks,
Danek