Missing feature: excluding certain commands from being added to history

[manfredlotz]

Unfortunately, there is no good possiblity to exclude certain commands from being added to history. bash has HISTIGNORE.

Could such a feature be added to fish? Of course, in a fish-like way instead of using a variable like in bash.

Thanks for considering.

[zanchey]

This is a duplicate of #2788, which we have decided against.

One workaround is to abbreviate the command you always want to hide to begin with a space, which prevents it from being saved:

abbr --add nonsaved ' nonsaved'

[manfredlotz]

That workaround is not bullet proof.
Let's say I type: nonsa<tab> and after completion the abbr won't used.

I guess you will tell me not to type nonsa<tab>. But sometimes this happens automatically, and I think it has to work.

[zanchey]

What version are you running? Abbreviations could not be tab-completed before 3.0.0.

[manfredlotz]

3.0.2

[manfredlotz]

Yesterday, I discussed things with Fabian, and he gave me a suggestion which I finalized like this:

function delete-mplayer --on-event fish_postexec
    string match -qr '^mplayer' -- $argv
    and history delete --exact --case-sensitive -- (string trim -r $argv)
end

This seems to work no matter if I tab-complete mplayer or type the whole command without completion

[manfredlotz]

I have to trim when tab-completion, and I have to have the trim inside the history command because if there is nothing to trim there is a status 1

Fabian was first confused why there was an additional blank but he found #4908 which explains why. So this is the reason I must trim

[manfredlotz]

For the records. It seem that this works fine.

set -l pgms  mplayer my_secret_cmd

for p in $pgms 
  function $p-del-hist --on-event fish_postexec -d "delete $p from history" --inherit-variable p
    string match -qr "^$p" -- $argv
    and history delete --exact --case-sensitive -- (string trim -r $argv)
  end
end

[faho]

This is a duplicate of #2788, which we have decided against.

This is a re-run. I'd like to reconsider.

The workaround has a lot of problems (not the least of which that it now requires trimming whitespace, but we want to do some normalization on history), so I'd like to provide some thing to make this easier.

I don't think $HISTIGNORE is a great interface, but a function that we execute to ask whether an element should be added would be alright.

E.g.

function fish_should_add_history
    for cmd in mplayer cd ls
       string match -qr "^$cmd" -- $argv; and return 1
    end
    return 0
end

Or alternatively we could make the "workaround" easier and nicer to use. Like not requiring --exact --case-sensitive. Or possibly a history forget-pending (see #5791).

[manfredlotz]

I agree that HISTIGNORE is not really attractive and of course it is not along the philosophical lines of fish.

I think my now functioning workaround is really just a workaround. So, your suggestion of offering a function whose return code decides if something gets added to the history of not, is best.

[ridiculousfish]

I like the function idea as well. The default version of the function could implement the leading-spaces-dropped-from-history behavior.

[vrotaru]

My 2 cents use case

export HISTIGNORE="vault write*"

Here, the point is that no sensitive information will be recorded in command history