history delete function seems inadequate for common use cases

[crabdancing]

Using fish version 3.0.2-661-g6e525cc5d on Arch Linux with uxterm.

The main thing I find myself using history delete for is clearing a password from the shell history. Thus it would be reasonable to expect it to be easy to delete, say, the last 10 lines from history, or the history from the current session (but spare all other history).

But the interface expects me to delete by search term instead, which wastes time when I could have just typed history clear-session or something like history delete -10 (to delete the last 10 lines, ideally without it bringing up a confirmation thing).

What does everyone think?

[floam]

If we made $history not read-only, this could be done with set -e history[1..10].

[mqudsi]

But this isn't a complaint about the inability to modify the history variable, rather the unfriendliness of the history builtin.

[crabdancing]

But this isn't a complaint about the inability to modify the history variable, rather the unfriendliness of the history builtin.

Yeah, exactly. I was a little bit incredulous reading the docs because I strongly expected it to have a function for clearing only the current session or for clearing the last X number of lines... I half expected someone to tell me that there was such a function that wasn't documented, which is why I didn't phrase this as a feature request.

[floam]

It seems like a reasonable feature request to me.

[InspectorMustache]

How about this elegant and not at all hacky workaround in the meantime:

for i in $history[1..10]
    history delete --exact --case-sensitive -- "$i"
end

[crabdancing]

@InspectorMustache That works great for now! I'll wrap it in a temporary function until this is fixed. ^.^ Thanks for the suggestion.

[mqudsi]

I think a nice approach (that would also address some of the concerns in #5482) would be to make a bare history delete trigger a read prompt for keywords to sanitize from the history, which would a) be easier to use, and b) take care of the privacy hole whereby history delete foo deletes foo from history but re-introduces it with a new history delete foo entry in history

I also like the idea of a separate history clear-session in addition to the existing history clear, this one wouldn't even need to ask for confirmation as it's No Big Deal™.

[faho]

bare history delete trigger a read prompt for keywords to sanitize from the history, which would a) be easier to use, and b) take care of the privacy hole whereby history delete foo deletes foo from history but re-introduces it with a new history delete foo entry in history

One problem: We keep a separate read history.

@mqudsi: That'll probably need to have some change for your mysql -uuser -p(read) idea.

[ridiculousfish]

+1 to history clear-session

[faho]

Yeah, I don't think #5904 is quite enough. I'd still like a history subcommand to forget the last couple of entries, up to the session (though I'm not sure if we currently have that definition?)

[faho]

history clear-session was merged in #8337, #9454 asks for dropping history via the pager.