trivial problem with histverify

trivial problem with histverify

[Ray Andrews]

I have this command bound to PgUp:

      history 1 | grep --color=auto "[[:digit:]]  !!"

... it does the obvious thing, I type a string I want to search for in 
history and get
a nice colored listing.  When recalling a command from history with '!', 
I like to
have 'setopt histverify' in case I want to edit the command, or just be 
sure I'm
going to execute the correct command before it fires.  However, if that 
option is
set, it fouls up the above keybinding in the predictable way, it demands 
ENTER
before it will work. It seems on the face of it that 'histverify' is not 
being very
smart about that, because the key binding isn't executing a command, it's
just making a listing.  It seems as if the test for 'histverify' is just 
seeing the
literal bangs in the key binding and not figuring out that there is 
really no command
being executed.  Is this really what we want?  If so, is there a simple 
work-around?
As it is, I just leave 'histverify' off, and try to be careful, so it's 
hardly important,
but I would  like to have it both ways if possible.

Re: trivial problem with histverify

[Mikael Magnusson]

On Mon, Dec 1, 2014 at 9:20 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> I have this command bound to PgUp:
>
>      history 1 | grep --color=auto "[[:digit:]]  !!"
>
> ... it does the obvious thing, I type a string I want to search for in
> history and get
> a nice colored listing.  When recalling a command from history with '!', I
> like to
> have 'setopt histverify' in case I want to edit the command, or just be sure
> I'm
> going to execute the correct command before it fires.  However, if that
> option is
> set, it fouls up the above keybinding in the predictable way, it demands
> ENTER
> before it will work. It seems on the face of it that 'histverify' is not
> being very
> smart about that, because the key binding isn't executing a command, it's
> just making a listing.  It seems as if the test for 'histverify' is just
> seeing the
> literal bangs in the key binding and not figuring out that there is really
> no command
> being executed.  Is this really what we want?  If so, is there a simple
> work-around?
> As it is, I just leave 'histverify' off, and try to be careful, so it's
> hardly important,
> but I would  like to have it both ways if possible.

If histverify is set or not doesn't change the fact that !! in your
command will expand as normal. If you want to suppress history
expansion you either have to disable the banghist option, or quote the
history character (!). Long story short is: '[[:digit:]] !!' will do
what you want (double quotes do not stop history expansion).

-- 
Mikael Magnusson

Re: trivial problem with histverify

[Ray Andrews]

On 12/01/2014 03:26 PM, Mikael Magnusson wrote:

> If histverify is set or not doesn't change the fact that !! in your 
> command will expand as normal. If you want to suppress history 
> expansion you either have to disable the banghist option, or quote the 
> history character (!). Long story short is: '[[:digit:]] !!' will do 
> what you want (double quotes do not stop history expansion). 

  There's no issue with expansion, I want it to expand just as it does.  
Here's the binding:

     bindkey -s "\e[5~" '\C-a print -s \C-e\C-m history 1 | grep 
--color=auto "[[:digit:]]  !!" \C-m'

... with 'histverify' off, it executes directly, on whatever text is on 
the command line, but with the variable on, I must press ENTER before it 
fires.  I'm guessing that the code that handles 'histverify' sees the " 
!! " and so demands the ENTER, but I'd say that in this situation that 
shouldn't be required since no history command is actually being 
executed, it's just a listing of string matches.  Or if it's agreed that 
that should indeed require the ENTER (when 'histverify' is active), I'm 
wondering if there's a workaround, so that my binding is exempt.  (BTW 
the " [[digit:]] " is just to keep the search to the beginning of  
history lines, after the number.) BTBTW it seems a strange way to 
capture whatever is on the command line but " print -s " was all that I 
could find that worked at the time.

Re: trivial problem with histverify

[Bart Schaefer]

On Dec 1,  4:10pm, Ray Andrews wrote:
}
} I'm guessing that the code that handles 'histverify' sees the " !! "
} and so demands the ENTER, but I'd say that in this situation

You're misinterpreting histverify.

It is not intended to verify that "a history command is actually being
executed."  It is intended to verify that in the text of any command in
which history was referenced, the correct history reference was made.

For example, suppose you typed

% rm -f !:4

(remove the file named by the fourth argument of the previous command).
Histverify allows you to see which file name is going to be removed
before it actually is removed.

} shouldn't be required since no history command is actually being 
} executed, it's just a listing of string matches.

You're giving the shell way too much credit for "knowing" what the
effects of the command are going to be.  You might have a command in
$HOME/bin named "grep" for "gamma radiation exposure percentage" or
"get rid of everyone please."

} wondering if there's a workaround, so that my binding is exempt

Don't use "!!" in the binding?

Honestly, how did it ever get that complicated?  Why print -s the words
into the history and then pull them back out again with "!!" rather
than just:

bindkey -s '\e[5~' '\C-a history 1 | grep "[[:digit:]]  \C-e"\C-m'

??  Which of course breaks if there are any double quotes in what you
typed before pressing page-up, but that was already the case.

} BTBTW it seems a strange way to

} could find that worked at the time.

This is a case where you should be writing a user-defined widget rather
than using "bindkey -s".

    grep-history() {
      (( HISTNO > 1 )) || return
      zle -I
      history 1 | grep --color=auto "[[:digit:]]  $BUFFER"
    }
    zle -N grep-history
    bindkey '\e[5~' grep-history

Better?

Re: trivial problem with histverify

[Ray Andrews]

On 12/01/2014 06:47 PM, Bart Schaefer wrote:
> It is not intended to verify that "a history command is actually being
> executed."  It is intended to verify that in the text of any command in
> which history was referenced, the correct history reference was made.
>
> For example, suppose you typed
...

I see.  I had the wrong notion. (What a surprise ;-)

> Honestly, how did it ever get that complicated?  Why print -s the words
> into the history and then pull them back out again with "!!" rather
> than just:
>
> bindkey -s '\e[5~' '\C-a history 1 | grep "[[:digit:]]  \C-e"\C-m'
I don't know how it got like that.  It seemed necessary at the time, but 
yours
works just as well, and makes more sense too.  At the time I just wanted it
to work and I haven't  thought about it since.  Looking back, I may have
built it up from this:

# Ctrl+H: put existing command line into history w.o. executing it first.
bindkey -s "^H" '\C-a print -s \C-e\C-m'

... which seems to need the 'print -s' action, so I got it into my head that
that was the only way to get a line into history without ENTER.

Oh, and of course it no longer trips over 'histverify' :-)


     grep-history() {
       (( HISTNO > 1 )) || return
       zle -I
       history 1 | grep --color=auto "[[:digit:]]  $BUFFER"
     }
     zle -N grep-history
     bindkey '\e[5~' grep-history



I haven't done a widget yet, this looks like a good place to start.

Thanks again sir.