From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17581 invoked by alias); 15 Oct 2013 16:58:48 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31824 Received: (qmail 26777 invoked from network); 15 Oct 2013 16:58:42 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f5-b7ef66d00000795a-dc-525d743fd73a Date: Tue, 15 Oct 2013 17:58:38 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Finer control over what gets written to the history file Message-id: <20131015175838.19f0256d@pwslap01u.europe.root.pri> In-reply-to: <131015094100.ZM2399@torch.brasslantern.com> References: <131015094100.ZM2399@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42I5/e/4NV37ktggg6fTtS0ONj9kcmD0WHXw A1MAYxSXTUpqTmZZapG+XQJXxtdFX5kLFgpXXO4va2B8ydvFyMkhIWAi8fPkFxYIW0ziwr31 bF2MXBxCAksZJT5c/c4I4Sxnkpj88CA7SBWLgKrE7Yl3WEFsNgFDiambZjOC2CIC4hJn154H myQs4CpxbuY0sDivgL3E73UrwGxOAUuJa1cuMIHYQgIWEq9uHgGz+QX0Ja7+/cQEcYW9xMwr Z6B6BSV+TL4HNpNZQF1i0rxFzBC2tsSTdxdYJzAKzEJSNgtJ2SwkZQsYmVcxiqaWJhcUJ6Xn GukVJ+YWl+al6yXn525ihITg1x2MS49ZHWIU4GBU4uFViI0NEmJNLCuuzD3EKMHBrCTCmwgS 4k1JrKxKLcqPLyrNSS0+xMjEwSnVwFhrHlyjvXzHphsupQwbrh1W4HF2TQi55PfkbVHUzN8n cy4z8a14tnlXkNLDvOXSlx/HlR/Nen0tVOd42K+LlwrWnNbgSXSSjb9m9n+XDGdRTCvvjJUH TVn+et0pP6XHcOSbBefdcwWqPPFXc293nGJ56OV3b+78q/Uza646X9Bfc/QTo813+34lluKM REMt5qLiRABkCCzGHwIAAA== On Tue, 15 Oct 2013 09:41:00 -0700 Bart Schaefer wrote: > I often find myself running a lot of similar but not quite identical > commands to test some obscure bug or otherwise experiment with a shell > construct. This stuff tends to push useful history out of the history > file when I exit from the shell, if I don't remember to use my "die" > alias that disables history and other exit-time operations. >=20 > It'd be nice to be able to selectively exclude those from history after > the fact, also without having to remember to type a leading space on > every such line. You know about the zshaddhistory hook? Excluding by pattern is a fairly easy instance of this, and it should be readily extensible for various different ways of checking. You could make it configurable by styles. zshistory_veto () { local -a line line=3D(${(Q)${(z)1}}) # too lazy to do the array stuff... if [[ $line[1] =3D ${~HISTIGNORE} ]] then return 1 fi } autoload -Uz add-zsh-hook add-zsh-hook zshaddhistory zshaddhistory_veto Just seen a typo. zshaddhistory Executed when a history line has been read interactively, but before it is executed. The sole argument is the complete his=E2= =80=90 tory line (so that any terminating newline will still be present). If any of the hook functions return a non-zero value the history line will not be saved, although it lingers in the history until the next line is executed allow you to reuse or edit it immedi=E2= =80=90 ately. A hook function may call `fc -p ...' to switch the history con=E2= =80=90 text so that the history is saved in a different file from the that in the global HISTFILE parameter. This is handled spe=E2= =80=90 cially: the history context is automatically restored after the processing of the history line is finished. The following example function first adds the history line to the normal history with the newline stripped, which is usually the correct behaviour. Then it switches the history context so that the line will be written to a history file in the current directory. zshaddhistory() { print -sr -- ${1%%$'\n'} fc -p .zsh_local_history } pws