zsh-users
 help / color / mirror / code / Atom feed
From: ZyX <kp-pav@yandex.ru>
To: Jochen Keil <jrk@sternenrei.ch>,
	Bart Schaefer <schaefer@brasslantern.com>,
	"zsh-users@zsh.org" <zsh-users@zsh.org>
Subject: Re: How to (properly) remove the last entry from history with command_not_found_handler
Date: Mon, 21 Jul 2014 21:46:44 +0400	[thread overview]
Message-ID: <11611421405964804@web8h.yandex.ru> (raw)
In-Reply-To: <53CC2B29.2030809@sternenrei.ch>



21.07.2014, 00:52, "Jochen Keil" <jrk@sternenrei.ch>:
> Hello Bart,
>
> On 20.07.2014 20:13, Bart Schaefer wrote:
>>  On Jul 20, 11:04am, Jochen Keil wrote:
>>  }
>>  } function command_not_found_handler()
>>  } {
>>  }     sed -i '$d' $HISTFILE
>>  }     return 127
>>  } }
>>  }
>>  } However, I'm not sure if it's ok to manipulate the history file directly
>>  } with sed, or if I'm risking corruption.
>>
>>  This is likely to be a problem if the failing command spans more than
>>  one line (e.g., a "for" loop with command-not-found in the middle of
>>  it) or if you are using SHARE_HISTORY where there's a race condition
>>  among shells reading the history and shells (re)writing it.
>>
>>  There really isn't any way to "properly" remove an entry once it has been
>>  written to the history file.  You might try some variation of this:
>>
>>    zshaddhistory() {  whence ${${(z)1}[1]} >/dev/null || return 2 }
>>
>>  There are still problems with that for multi-line commands but the right
>>  way to achieve your desired behavior is to avoid writing out the commands
>>  you don't want, not to write them and then delete them again.
>
> It was my first thought too, to avoid adding the command at all.
> However, I misunderstood/misinterpreted the explanation of the
> zshaddhistory hook in the manual. Anyhow, your version works very well,
> thank you!
>
> Nevertheless, I start to see why this is probably a not so good idea (or
> at least pretty hard to implement). For example:
>
>   $ echo "test"; echox "test"
>
> This is similar to the multi-line example. One basically needs to split
> up the command at semicolons and newlines. Then one needs to decide
> which of the subcommands is correct and which one not. Finally one needs
> to decide if an altered version of the command should go to the history
> file or none at all.
>
> I think the possible gains are not worth the effort. I'll stick to your
> solution as it covers most of the cases which I care most about: When
> I've accidentally mistyped a command or entered other garbage.
>
> Thank you very much again and best wishes,
>
>   Jochen

Are you sure you need to *remove* that entry? I can suggest another approach: defer adding history item until you are sure you can add it:

    _record_history_item() {
        typeset -g _LASTHISTITEM="${1%%$'\n'}"
        return 2  # Never record history at this point
    }
    zshaddhistory_functions+=(_record_history_item)

    _add_history_precmd() {
        if test -n "$_LASTHISTITEM" ; then
            print -sr -- "$_LASTHISTITEM"
        endif
    }
    precmd_functions+=(_add_history_precmd)

Then all your handler need is to use

    _LASTHISTITEM=

to drop history item. I did not test my code though.


      reply	other threads:[~2014-07-21 17:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-20  9:04 Jochen Keil
2014-07-20 17:45 ` Peter Stephenson
2014-07-20 18:13 ` Bart Schaefer
2014-07-20 20:48   ` Jochen Keil
2014-07-21 17:46     ` ZyX [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11611421405964804@web8h.yandex.ru \
    --to=kp-pav@yandex.ru \
    --cc=jrk@sternenrei.ch \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).