precmd() bug.

precmd() bug.

[John Benninghoff]

I am having the following problem using the precmd() function:

jb@geko zsh: precmd() { temp=$(date) }
jb@geko zsh: r vi
vi .zshrc
zsh: command not found: datevi
jb@geko zsh: unfunction precmd
jb@geko zsh: r vi
vi .zshrc
jb@geko zsh: 

When I use the r builtin and my precmd() uses the $() command substitution,
the command line appears to get confused(i.e. datevi).  I'm running
zsh2.5.03.  Is this a known problem?  Any workaround/fix?

I'm not on the zsh-list so please Cc me on any replies.

/John Benninghoff

Re: precmd() bug.

[P.Stephenson]

John.Benninghoff@eng.sun.com wrote:
> I am having the following problem using the precmd() function:
> 
> jb@geko zsh: precmd() { temp=$(date) }
> jb@geko zsh: r vi
> vi .zshrc
> zsh: command not found: datevi

Yes, it's still there.

Here's what's happening:  The `r' command forces 'vi .zshrc' into the
input stream, assuming it's going to be parsed the next time the shell
wants some input from the keyboard.  Instead, the $(...) command
forces its own stuff (`date') into the input list, not realising
there's anything there, so the next precmd() to come along ends up
trying to evaluate 'datevi .zshrc' in the command substitution.
It's related to another problem reported some time ago:
% echo foo
% print $(r)
which should print out `echo foo' then `foo' (by evaluating `print
$(echo foo)', like it does in ksh, but instead just gives you `echo
foo', since the `r' stuff doesn't actually get executed, just force
into the input stream.

Here's what should happen.  Instead of forcing the stuff into the
input stream for the next command, the `r' command (actually any `fc
-e' command) in bin_fc() should print the command (to the shell output
`shout' rather than stdout or stderr, if ksh is anything to go by),
add it to the history list, and execute it straight away as if it had
been there instead of the `r' command.  The most difficult bit is the
middle one: the history code is rather unpleasant and works by
deleting command lines it doesn't think should remain there, rather
than adding the ones it thinks should.  Unfortunately it's set up so
that it only keeps commands which come from the terminal and it looks
rather difficult at present to adapt it reliably so that you only get
the commands you want in the history list.  Ideally, the whole history
code could do with consigning to oblivion and being rewritten from the
ground up.

Another history gripe: the histnostore option (don't leave history
commands in the history list) is broken **YET AGAIN** --- I've fixed
it twice myself and I can't be bothered to do it again.  It's related
(like it was the previous two times) to the off-by-one error which
won't let you show just the last command using `history'.  I suppose
it's too much to hope that whoever broke it is going to fix it.
Perhaps my last patch never made it, but it's so long ago now it's
impossible to check.

-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.