Append cancelled commands to history

Append cancelled commands to history

[thomasg]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

Hello list,

I was curious if it's possible to append canceled (CTRL+C) commands to the
histfile.
In case there is not yet a function to do this, is it generally possible to
bind CTRL+C to a custom function?

Greetings,

thomasg

[-- Attachment #2: Type: text/html, Size: 280 bytes --]

Re: Append cancelled commands to history

[Simon Ruderich]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Thu, Sep 18, 2008 at 11:50:42PM +0200, thomasg wrote:
> Hello list,
>
> I was curious if it's possible to append canceled (CTRL+C) commands to the
> histfile.
> In case there is not yet a function to do this, is it generally possible to
> bind CTRL+C to a custom function?
>
> Greetings,
>
> thomasg

Hi,

I'm using the following function which works fine for me, not sure though if
it's the best solution:

    TRAPINT() {
        # Store the current buffer in the history.
        zle && print -s $BUFFER

        # Return the default exit code so zsh aborts the current command.
        return $1
    }

Hope this helps,
Simon
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re[2]: Append cancelled commands to history

[Vadim Zeitlin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1130 bytes --]

On Fri, 19 Sep 2008 18:20:45 +0200 Simon Ruderich <simon@ruderich.org> wrote:

SR> I'm using the following function which works fine for me, not sure though if
SR> it's the best solution:
SR> 
SR>     TRAPINT() {
SR>         # Store the current buffer in the history.
SR>         zle && print -s $BUFFER
SR> 
SR>         # Return the default exit code so zsh aborts the current command.
SR>         return $1
SR>     }

 Hello,

 I've been using this tip since the day it was posted here and it worked
great: pressing Ctrl-C is much more convenient/easier to remember than
using a separate key combination for "cancel but save in history" that I
used before, thanks Simon! However today I accidentally found out that
pressing Ctrl-C on a line starting with '-' results in

	TRAPINT:1: bad option: -

error message. The fix for this is, of course, obvious but I thought to
post it here just in case anybody else decides to copy this from the list
archives to their .zshrc, so here is the updated function:

	% which TRAPINT
	TRAPINT () {
		zle && print -s -- $BUFFER
		return $1
	}

 Thanks again to Simon for the original tip!
VZ

[-- Attachment #2: Type: APPLICATION/PGP-SIGNATURE, Size: 187 bytes --]

Re: Append cancelled commands to history

[Nadav Har'El]

On Mon, Jul 06, 2009, Vadim Zeitlin wrote about "Re[2]: Append cancelled commands to history":
> 		zle && print -s -- $BUFFER

I wonder, isn't "-r" also wise to add, otherwise if you have escape sequences
like "\n", "\c", etc., in your command line, they will be modified by the
print command?

-- 
Nadav Har'El                        |      Monday, Jul  6 2009, 15 Tammuz 5769
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |echo '[q]sa[ln0=aln256%Pln256/snlbx]
http://nadav.harel.org.il           |sb3135071790101768542287578439snlbxq'|dc

Re: Append cancelled commands to history

[Nadav Har'El]

On Mon, Jul 06, 2009, Nadav Har'El wrote about "Re: Append cancelled commands to history":
> > 		zle && print -s -- $BUFFER
> 
> I wonder, isn't "-r" also wise to add, otherwise if you have escape sequences
> like "\n", "\c", etc., in your command line, they will be modified by the
> print command?

I added another trick: It annoyed me that if I go back in history and change
my mind, pressing interrupt now will save the whatever command I moved back
to again in the front of the history. I wanted the interrupt key to only save
a new command.
So I added a check for this, using the HISTNO and HISTCMD variables we have
access to: If those are equal, we're editing a new command, but if they're
not, we're on an old command from the history:

# When a line is killed, put it in the history anyway in case we want to
# return to it
TRAPINT() {
        # Store the current buffer in the history.
        zle && 
        [[ $HISTNO -eq $HISTCMD ]] && # only if we're not back in the history
        print -s -r -- $BUFFER

        # Return the default exit code so zsh aborts the current command.
        return $1
}


-- 
Nadav Har'El                        |      Monday, Jul  6 2009, 15 Tammuz 5769
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Ways to Relieve Stress #10: Make up a
http://nadav.harel.org.il           |language and ask people for directions.

Re: Append cancelled commands to history

[Nadav Har'El]

Last year, a discussion started on this list on how to save a partially
typed command to the history when you press the interrupt key - so that
you can return to this command later.

>From ideas of several people, we built the following simple function:

On Mon, Jul 06, 2009, Nadav Har'El wrote about "Re: Append cancelled commands to history":
> # When a line is killed, put it in the history anyway in case we want to
> # return to it
> TRAPINT() {
>         # Store the current buffer in the history.
>         zle && 
>         [[ $HISTNO -eq $HISTCMD ]] && # only if we're not back in the history
>         print -s -r -- $BUFFER
> 
>         # Return the default exit code so zsh aborts the current command.
>         return $1
> }

This runs on interrupt and saves the currently edited ZLE buffer to the
history, but only if we were editing a new command (if I go up the history
and then press interrupt, I see no reason to save the old command again in
my history): 

But now I have a new problem. I want this to also work when editing multi-line
commands, e.g., if I start typing

	for i in *
	do

and then right after the do - without a newline - I press interrupt, I want
to be able to later go up the history to continue editing this command.

I thought this would be simple - just replace the print line with
	print -s -r -- "$PREBUFFER$BUFFER"

to print the full multiline command. But the strange thing is: It appears
that when I kill a multiline zle, zsh already (regardless of my function)
saves all the previous lines except the one now edited (i.e., saves $PREBUFFER)
to the history, so with my function the command is saved twice, once without
the first line, and once with the first line.

Does anyone know why zsh saves interrupted partial multiline commands, but
without their last line? Can this be avoided? And what was the rationale
to save the beginning of a multiline command and not everything - or not
at all for a single line command?

Thanks,
Nadav.


-- 
Nadav Har'El                        |        Monday, Mar 15 2010, 1 Nisan 5770
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Always go to other people's funerals,
http://nadav.harel.org.il           |otherwise they won't come to yours.

Re: Append cancelled commands to history

[Bart Schaefer]

On Mar 15,  6:42pm, Nadav Har'El wrote:
>
> Does anyone know why zsh saves interrupted partial multiline commands,
> but without their last line?

Every time a new prompt is printed -- even if it's the PS2 prompt rather
than the top-level prompt -- is a new "instance" of the line editor.
Looked at another way, as soon as you hit "enter" (accept-line) the
current $BUFFER is stored in the "pending history".  You can't yet
scroll back to it from the following PS2 prompt, but it has been
remembered as something you input and might want to revisit later.

Conversely, if you hit the interrupt key or ctrl-g (send-break), the
current buffer has not been stored and ZLE presumes that interruption
means you DON'T want to revisit this later.  You can subvert the latter
behavior, but because a new ZLE instance started at accept-line, it's
already too late to subvert the former.

> Can this be avoided? And what was the rationale to save the beginning
> of a multiline command and not everything - or not at all for a single
> line command?

There's a reason the widget is called "accept-line".  If the line has
been accepted (even if it doesn't form a complete command yet), it's
something you want; if you "send-break" or do an interrupt, it's not
accepted and therefore something you don't want.

> I thought this would be simple - just replace the print line with
> 	print -s -r -- "$PREBUFFER$BUFFER"

Hmm.  When I use TRAPINT, $PREBUFFER is always empty.

torch% print $ZSH_VERSION $ZSH_PATCHLEVEL 
4.3.10-dev-1 1.4940

Re: Append cancelled commands to history

[Nadav Har'El]

On Sat, Mar 20, 2010, Bart Schaefer wrote about "Re: Append cancelled commands to history":
> > I thought this would be simple - just replace the print line with
> > 	print -s -r -- "$PREBUFFER$BUFFER"
> 
> Hmm.  When I use TRAPINT, $PREBUFFER is always empty.
> 
> torch% print $ZSH_VERSION $ZSH_PATCHLEVEL 
> 4.3.10-dev-1 1.4940

Thanks for the explanations. For me, $PREBUFFER does work:

$ print $ZSH_VERSION $ZSH_PATCHLEVEL
4.3.10 1.4705
$ cat /etc/redhat-release; rpm -qf =zsh
Fedora release 12 (Constantine)
zsh-4.3.10-4.fc12.x86_64

$ functions TRAPINT
TRAPINT () {
        zle && [[ $HISTNO -eq $HISTCMD ]] && print -s -r -- "$PREBUFFER$BUFFER"
        echo "prebuffer: '$PREBUFFER'"
        return $1
}

$ for i in *
for> do
for> echo<INTERRUPT>prebuffer: 'for i in *
do
'

$

But the problem I have now is that when I now go up in the history, the
last command I see is

	for i in *
	do

which is what standard zsh saved - without the last partial line - and when I
go up another command in history I see

	for i in *
	do
	echo

which is what my code saved. I wished there was a way not to save that
shorter version, with only the accepted lines.

Of course, it's not so terrible as it is - I just wondered if there's a
way to do it better. Usually when I interrupt a multi-line command entry,
it's not because I'm not pleased with the last line I typed (if this was
the case, I could have just backspaced...), but rather, I'm not pleased
with the whole thing. So I want to save the whole thing (including the
last line I'm editing), and go to edit it later if I wish.


-- 
Nadav Har'El                        |        Monday, Mar 22 2010, 7 Nisan 5770
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Why do we drive on a parkway and park on
http://nadav.harel.org.il           |a driveway?

Re: Append cancelled commands to history

[Bart Schaefer]

On Mar 22, 10:42am, Nadav Har'El wrote:
> Subject: Re: Append cancelled commands to history
>
> But the problem I have now is that when I now go up in the history, the
> last command I see is
> 
> 	for i in *
> 	do
> 
> which is what standard zsh saved - without the last partial line - and when I
> go up another command in history I see
> 
> 	for i in *
> 	do
> 	echo
> 
> which is what my code saved. I wished there was a way not to save that
> shorter version, with only the accepted lines.

Something like this may work:

typeset -g INTBUFFER
autoload -U add-zsh-hook

trapint_history() {
   if [[ -n "$INTBUFFER" ]]
   then
      print -s -r -- "$INTBUFFER"
      INTBUFFER=
      return 1
   fi
   return 0
}

TRAPINT() {
   zle && [[ $HISTNO -eq $HISTCMD ]] && INTBUFFER="$PREBUFFER$BUFFER"
   return $1
}

add-zsh-hook zshaddhistory trapint_history

-- 

Re: Append cancelled commands to history

[Nadav Har'El]

On Mon, Mar 22, 2010, Bart Schaefer wrote about "Re: Append cancelled commands to history":
> On Mar 22, 10:42am, Nadav Har'El wrote:
> Something like this may work:
>...

Thanks! I wasn't aware of the zshaddhistory hook. Zsh has improved since
I last read its manual from cover to cover (circa 1995) :-)

Anyway, I tried what you wrote, and it didn't work because it appears the
zshaddhistory hook does not get called when I interrupt the ZLE.

But, further experimentation yielded that my problem is caused by something
either stranger:

Without any special hooks or trapint, if you try entering a multiline command
like

	for i in 1 2 3
	do

and then interrupt it, if you now go up in history you'll see this interrupted
command (but not the last line you interrupted on).
BUT, if you now run "history", you don't see this line! Even stranger, after
you run that "history" command and you try to go up, you no longer find this
history line.

So apparently, that interrupted multiline editing is *not* in the history,
and never was. So where is it? Why do I see it when I go "up" for the first
time? How do I prevent this? Again, I didn't find the relevant places in
the code :(

Thanks,
Nadav.


-- 
Nadav Har'El                        |     Wednesday, Mar 24 2010, 9 Nisan 5770
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |I want to be a human being, not a human
http://nadav.harel.org.il           |doing -- Scatman John

Re: Append cancelled commands to history

[Bart Schaefer]

On Mar 24, 12:27pm, Nadav Har'El wrote:
}
} Anyway, I tried what you wrote, and it didn't work because it appears the
} zshaddhistory hook does not get called when I interrupt the ZLE.

Ah.  That makes sense.  I was assuming it didn't work for me because
of the $PREBUFFER-is-empty problem (for which a patch has since been
posted on zsh-workers).

} So apparently, that interrupted multiline editing is *not* in the
} history, and never was. So where is it? Why do I see it when I go "up"
} for the first time? How do I prevent this?

Oh, of course.  Zsh *always* makes the immediately preceding accepted
input available for scrollback in the line editor, even if it was not
put into the history (because of HIST_IGNORE_ALL_DUPS, HIST_NO_STORE,
or HIST_IGNORE_SPACE, etc.).

There is no way to prevent this.

You could, however, stop using the interrupt signal and its trap, and
instead re-bind ctrl-C (or whatever your interrupt key is) to a zle
function that, whenever $PREBUFER is non-empty, does a no-op equivalent
of accept-line followed by a send-break.

    typeset -gi INTR_PRESSED=0

    finish_simulated_interrupt() {
      if (( INTR_PRESSED ))
      then
	INTR_PRESSED=0
	return 1
      else
	return 0
      fi
    }
    add-zsh-hook preexec finish_simulated_interrupt

    simulate-interrupt() {
      if [[ -n $PREBUFFER ]]
      then
	INTR_PRESSED=1
	zle -U $'\a'	# Replace with your send-break keystroke
	zle accept-line
      else
	zle send-break
      fi
    }
    zle -N simulate-interrupt

Rebinding keys to call simulate-interrupt instead of sending a real
terminal driver interrupt, is left as an exercise.

-- 

Re: Append cancelled commands to history

[Nadav Har'El]

On Wed, Mar 24, 2010, Bart Schaefer wrote about "Re: Append cancelled commands to history":
> } So apparently, that interrupted multiline editing is *not* in the
> } history, and never was. So where is it? Why do I see it when I go "up"
> } for the first time? How do I prevent this?
> 
> Oh, of course.  Zsh *always* makes the immediately preceding accepted
> input available for scrollback in the line editor, even if it was not
> put into the history (because of HIST_IGNORE_ALL_DUPS, HIST_NO_STORE,
> or HIST_IGNORE_SPACE, etc.).
> 
> There is no way to prevent this.

Thanks. I think I understand better now what is happening. What I still find
a bit odd is the fact that this behavior (of saving the partially entered
command in a special place outside the history) is only applied to whole
lines of multiline commands, and not to interrupted single line commands,
or to the last partially-written line of a multiline command. I have two
reservations about this behavior:

1. Why this should apply only to multi-line commands

2. Why is that special (out of history) memory location for one last command
   is needed, or even desired. If it was added, I assume people wanted to
   scroll back to it. Now, what happens if you accidentally run some other
   command and only then wish to scroll back to that interrupted command?
   You can't. So what's wrong with just using the normal history to store it?

> You could, however, stop using the interrupt signal and its trap, and
> instead re-bind ctrl-C (or whatever your interrupt key is) to a zle
> function that, whenever $PREBUFER is non-empty, does a no-op equivalent
> of accept-line followed by a send-break.

Thanks! Maybe I'll indeed try that. I'm a bit reluctant, though, to go
through all this complexity just to avoid that extra partial history
(or not really history :-)) entry. Because, like I said, the simple 4-line

TRAPINT() {
        zle && [[ $HISTNO -eq $HISTCMD ]] && print -sr -- "$PREBUFFER$BUFFER"
        return $1
}

already saves the partial command (single or multi-line) correctly.

Thanks again for your explanations, and I'll try your trick later.

Nadav.


-- 
Nadav Har'El                        |       Friday, Mar 26 2010, 12 Nisan 5770
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Strike not only while the iron is hot,
http://nadav.harel.org.il           |make the iron hot by striking it.

Re: Append cancelled commands to history

[Bart Schaefer]

On Mar 26, 11:23pm, Nadav Har'El wrote:
}
} What I still find a bit odd is the fact that this behavior (of saving
} the partially entered command in a special place outside the history)
} is only applied to whole lines of multiline commands, and not to
} interrupted single line commands

Once again, it depends on whether you interrupt an instance of the line
editor.  Every time you hit "enter", you've completed one instance of
the line editor and started a new one.  You're not interrupting a
syntactic construct, you're interrupting an editor instance.

If you were to write the entire multi-line construct in a single editor
instance, by using ESC-Enter to input literal newlines without starting
a new PS2 prompt, then the interrupt would discard the entire multi-
line command just as it discards a single-line command.

} 2. Why is that special (out of history) memory location for one last
}    command is needed, or even desired.

It's derived from the way that history references work in csh.  Even
if you set HISTSIZE=0 so that no history is ever saved, references to
the immediately preceding command with the "!!" syntax are required
to work.  Hence that preceding command is always kept around, and
there's no good reason not to allow you to scroll back to it with the
line editor.

As I mentioned before, it's also related to the options that allow you
to automatically exclude things from the history file (especially the
HIST_NO_STORE and HIST_IGNORE_SPACE options).  The most frequent
reason to want to retrieve a line from the history is because you
made a typo.  If you make a typo on a line you otherwise intend to
exclude from the history, wouldn't you find it annoying to have to
re-type the whole line?

Re: Append cancelled commands to history

[Simon Ruderich]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Mon, Jul 06, 2009 at 06:43:09PM +0300, Nadav Har'El wrote:
> On Mon, Jul 06, 2009, Vadim Zeitlin wrote:
>> 		zle && print -s -- $BUFFER
>
> I wonder, isn't "-r" also wise to add, otherwise if you have
> escape sequences like "\n", "\c", etc., in your command line,
> they will be modified by the print command?

I totally overlooked that mail.

Yes, -r is definitely a good idea, it fixed some trouble I had
with whitespace.

Thanks,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Append cancelled commands to history

[Simon Ruderich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jul 06, 2009 at 05:16:42PM +0200, Vadim Zeitlin wrote:
>  Hello,
>
>  I've been using this tip since the day it was posted here and it worked
> great: pressing Ctrl-C is much more convenient/easier to remember than
> using a separate key combination for "cancel but save in history" that I
> used before, thanks Simon! However today I accidentally found out that
> pressing Ctrl-C on a line starting with '-' results in
>
>     TRAPINT:1: bad option: -
>
> error message. The fix for this is, of course, obvious but I thought to
> post it here just in case anybody else decides to copy this from the list
> archives to their .zshrc, so here is the updated function:
>
>     % which TRAPINT
>     TRAPINT () {
>         zle && print -s -- $BUFFER
>         return $1
>     }

Hi Vadim,

Thanks for the fix. I just updated my TRAPINT function.

>  Thanks again to Simon for the original tip!
> VZ

I'm glad you like it ;-)

Simon
- -- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKU6bcAAoJEJL+/bfkTDL5/dcP/2U6iokXcnD/hLkGCIMndylJ
kkhgG2aHi/Ag7RlQh920CP3ApTVnLVb87rRlqglVV1OmBfanYHPpffeDr43nR1Wz
YI6TGU9Ak9g/Rt5deFEIAbR0wlg4CM8gKohlXpvKxZHi+AEr4toQKQo5T/Y/kWOm
xJ/xZLRipouytwsu9SD+t2F8/sKxHufvCdNr+JgiHL9rjjgF6uMwBu63tJ6YQIRn
wWQm2FAJMpwKAULCKcxRdGXRZhZRfvRB1yCD24uLlWN0xLDOLsFpchlW3xDdfG+1
fWJeAYn2Xhd4IISVvilAqq0g0DGWrtQI3+e4xb4UIIzFGiqPwoNLhaCK5oxPCcHh
FMa8dJKWaal3r9Nfc7w9/SeNoWbtdxHj/HxLdUtrO2ow4sZ9W68X2BgaF2b2vF4s
rM56fnRvlQqtA7MqYwBIRQv97ZL6QoIvwQyjwOvE2exD7hTtwHAm0fk3CMApixXR
56fdniiD5f/OtTAma72E72quc2naqURlthQWLsvAwanXEvAHy4vdkhkI+r2QoeVC
x4hSCkRLJ00SagSjX9+Ns86Tacj3RaWcvRpbjFqKIoXmYWtqQduL017Q24NP9dxJ
3T4g6zuTblju8rzQexMWBT4dd2TyrKmCb44MEABLU0Xy/1KyLRXZjD00egnRTBmH
zwSTYs9mmdYG3Wdk/kmc
=W7MA
-----END PGP SIGNATURE-----