spaceflag question; remhist() going away

spaceflag question; remhist() going away

[Wayne Davison]

There's a variable that gets set in input.c called "spaceflag".  It
gets set if the first character of the first line is a space.  Later
on, the history code checks this flag when the HIST_IGNORE_SPACE
option is set.  Can anyone tell me why the history code doesn't just
check if (*chline == ' ') instead of checking spaceflag?  I've removed
this variable from my local source, and everything appears to be
working just fine without it.

In a related area, I've dumped the function remhist() in my local
source.  This function is a constant source of bugs, and I found
yet another bug today:  if you have HIST_IGNORE_SPACE set along
with HIST_NO_STORE, you lose a line of history every time you type
" history" (note the leading space).

I've been wanting to dump remhist() for some time now due to how it
does not properly interact with the INC_APPEND_HIST & SHARE_HISTORY
options.  My solution is to use string matching of the command line
to determine if this is a command that should not be saved.  I'm also
considering adding a general-purpose environment variable that would
allow the user to specify an arbitrary pattern that would cause the
current command line not to be stored in the history.  I was thinking
about calling it $HISTIGNOREMATCH.

Comments are welcomed.

..wayne..

Re: spaceflag question; remhist() going away

[Peter Stephenson]

Wayne wrote:
> There's a variable that gets set in input.c called "spaceflag".  It
> gets set if the first character of the first line is a space.  Later
> on, the history code checks this flag when the HIST_IGNORE_SPACE
> option is set.  Can anyone tell me why the history code doesn't just
> check if (*chline == ' ') instead of checking spaceflag?
... 
> In a related area, I've dumped the function remhist() in my local
> source.  This function is a constant source of bugs, and I found
> yet another bug today:  if you have HIST_IGNORE_SPACE set along
> with HIST_NO_STORE, you lose a line of history every time you type
> " history" (note the leading space).

The history of history is hidden in prehistory.  It's probably best to
remove this stuff and then fix the problems which turn up later.  I've
always hated remhist() and have fixed at least two bugs in it without
counting everyone else's.

One possible reason for spaceflag might be that originally zsh kept lexical
and literal history separately so might not have known if the first word
began with a space.  But as far as I know chline has always been there, so
that's probably wrong.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: spaceflag question; remhist() going away

[Wayne Davison]

On Mon, 17 Jul 2000, Peter Stephenson wrote:
> One possible reason for spaceflag might be that originally zsh kept
> lexical and literal history separately so might not have known if
> the first word began with a space.

My current theory is that the flag used to also be used in another
section of code that checked if any of the expanded aliases began with
a space.  I had no idea that this code existed before I removed it
from my local version.  Also, the code doesn't seem to work in the
versions of zsh that I have access to (a slightly modified 3.0.6 and
the very latest CVS version), so I don't plan to re-implement this
space-starting-alias functionality (at least, not right away).

..wayne..

Re: spaceflag question; remhist() going away

[Bart Schaefer]

On Jul 16,  6:54pm, Wayne Davison wrote:
} Subject: spaceflag question; remhist() going away
}
} There's a variable that gets set in input.c called "spaceflag".  It
} gets set if the first character of the first line is a space.  Later
} on, the history code checks this flag when the HIST_IGNORE_SPACE
} option is set.  Can anyone tell me why the history code doesn't just
} check if (*chline == ' ') instead of checking spaceflag?

My theory was going to be the same as PWS's, but now I think I recall
something different; more in a moment.

} I've removed
} this variable from my local source, and everything appears to be
} working just fine without it.

I'll bet it isn't.  In an unmodified 3.0.[678] try this:

zsh% setopt histignorespace
zsh% alias echo=' echo'
zsh% echo foo
foo
zsh% history
setopt histignorespace
alias echo=' echo'
zsh% 

Note that aliases beginning with a space cause the line to be omitted from
the history even if the line itself did not begin with a space.

} I've been wanting to dump remhist() for some time now due to how it
} does not properly interact with the INC_APPEND_HIST & SHARE_HISTORY
} options.  My solution is to use string matching of the command line
} to determine if this is a command that should not be saved.

I don't care about removing remhist() one way or another, but the way
you were supposed to implement having an arbitrary command never appear
in your history was to create an alias starting with a space for that
command's name, as I did above with "echo".

I have no idea why this was never documented.

} I'm also
} considering adding a general-purpose environment variable that would
} allow the user to specify an arbitrary pattern that would cause the
} current command line not to be stored in the history.  I was thinking
} about calling it $HISTIGNOREMATCH.

I like the existing aliasing solution better; under what circumstances
would you want to match more of the command line than the command name?

On Jul 17,  3:04am, Wayne Davison wrote:
} Subject: Re: spaceflag question; remhist() going away
}
} My current theory is that the flag used to also be used in another
} section of code that checked if any of the expanded aliases began with
} a space.  I had no idea that this code existed before I removed it
} from my local version.  Also, the code doesn't seem to work in the
} versions of zsh that I have access to (a slightly modified 3.0.6 and
} the very latest CVS version)

As I pointed out above, if it doesn't work in your modified 3.0.6, it's
not my fault.

} so I don't plan to re-implement this
} space-starting-alias functionality (at least, not right away).

I hope you change your mind.

-- 
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: spaceflag question; remhist() going away

[Wayne Davison]

On Mon, 17 Jul 2000, Bart Schaefer wrote:
> I like the existing aliasing solution better; under what circumstances
> would you want to match more of the command line than the command name?

The matching rule would allow more general command-name rules, plus
line-oriented rules that name-oriented support don't allow.  For
instance:  ignoring lines that are just 1 or 2 chars long; ignoring
the make command unless it had an argument or was a part of a compound
statement; ignoring the history command, but only if it is not a part
of a compound statement (such as having its output piped into a
script); ignoring lines that begin with whitespace (including tab)
without having any extra alias-checking rules done; ignoring a lynx
command that uses the -auth option; etc.

The plus side is that a line-matching rule is much more flexible.  The
down side is that a user has to understand complex patterns to be able
to use it effectively.  Some good examples would get the casual user
going, though.

> } so I don't plan to re-implement this space-starting-alias
> } functionality (at least, not right away).
> 
> I hope you change your mind.

I have been considering how to do this even while not planning to
fiddle with it right away.  I think the easiest way to get it done
would be to have the history code look up the line's first word in
the aliases, and check it for a space.  This might be slightly more
restrictive than the old code which (I believe) would ignore the
line if any command in a sequence of commands was aliased to start
with a space, but that functionality doesn't strike me as very
desirable anyway (since compound commands are often the ones you
most want to save).

Since this functionality was never documented and since nobody using
the 3.1.x codebase has (apparently) ever missed it, I'm wondering if
we should just leave it out.  It shouldn't be hard to add the check I
described above if we think we need it, though, so after I get the
pattern stuff implemented, I may just go ahead and take a look at it.

Anyone else want to add their opinion to the subject?

..wayne..

Re: spaceflag question; remhist() going away

[Wayne Davison]

On Mon, 17 Jul 2000, Wayne Davison wrote:
> It shouldn't be hard to add the check I described above [...] I may
> just go ahead and take a look at it.

FYI, while I was enhancing the HIST_NO_STORE support to work with
aliased commands, I went ahead and added this too.  So, this space-
starting alias support will get fixed when I eventually check in.

..wayne..

Re: spaceflag question; remhist() going away

[Felix Rosencrantz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1682 bytes --]

 Wayne Davison wrote:
>The matching rule would allow more general command-name rules, plus
>line-oriented rules that name-oriented support don't allow.  For
>instance:  ignoring lines that are just 1 or 2 chars long; ignoring
>the make command unless it had an argument or was a part of a compound
>statement; ignoring the history command, but only if it is not a part
>of a compound statement (such as having its output piped into a
>script); ignoring lines that begin with whitespace (including tab)
>without having any extra alias-checking rules done; ignoring a lynx
>command that uses the -auth option; etc.
>
>The plus side is that a line-matching rule is much more flexible.  The
>down side is that a user has to understand complex patterns to be able
>to use it effectively.  Some good examples would get the casual user
>going, though.

Yeah, I was talking about something similar that could be used with
Bart's new smart-insert-last-word widget.  Seems like some common ability
to match and filter history would be useful in several situations.  Sort of
a regex for command history... 8)

Another thing I would use is a "soft" or "fuzzy" history mechanism.  For
example, I would really like to be able to intercept a "!$" history option
and replace it with a call to smart-insert-last-word (w/command line matching).
Or the ability to intercept other history calls like !* or !!.  It seems like
it would be useful to have an option that would allow us to play with this
history mechanism, so it's a little more DWIM.

-FR

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/