No one ever addresses the most important problem: how to separate commands that one would like to retain (preferably indefinitely) vs garbage commands (like cd, ls, cat, etc.) that should better be wiped in a few days.
ls I usually don't care about, but there are directories I regularly cd to, so it would be nice to have those in history.
I can think of a neat heuristic, which is that I often cd to an absolute or home directory, so if the path starts with / or ~ I'll possibly want to cd there again in the future. Changing to a relative path on the other hand, I tend to do more rarely and while doing more ephemeral work.
* prefix with space the commands you don't want to keep
* edit your existing .bash_history by prefixing all commands with space (then reload with history -r)
* after session exit or on next login, edit the new commands at the end (vi ~/.bash_history && history -r)
* use comments on the commands to make it easy to search (use keywords)
* group command lines by category (e.g. package manager, git, ssh, backup, find, dev)
2. I just don't want to be conscious about that every time I write a command. I'd rather edit history after I've finished some work. But that's just too tedious to do manually, I'd like to have some pre-configured heuristics applied automatically, like "never save cd/ls to history", but provide a way to overrule that rule in rare situations.
3. Absolute/partial/symlinked paths - are another separate problem :'(
Coming back several months later to be gifted with several, very similar commands of which only one is right can be frustrating. The history records the failed tries as well as the successes.
Mind, the errors give a place to start, but if it’s far enough removed from the original event it may well be ambiguous enough to send you to a search engine anyway, especially if you have the memory of a goldfish like I do.
The correct command is almost always the last one, so as long as your search results are chronological this shouldn't be an issue?
In SQL there are sessions and transactions. In shell history - we don't have such entities and this sucks. One could configure their bash/zsh to save history into separate files, but you can't teach them later to source them properly (retaining session awareness).
Sequential context is something we're building very soon. The idea: you search for "cd /project/dir", press TAB and it opens up a new pane in the tui. This will show the command +/- 10 commands. You can then navigate back in time.
This could indeed be useful for managing that one setup command you always have to run in this project dir but never remember the name of
Good to hear, but the point stands: so you deduplicate only for the view, not in the source, and thus the source remains contaminated with duplicates (at very least they cost some disk space and increase seek time).
As for the view: so, since you deduplicate the commands - you can't lookup the context (commands executed before & after)! Because each time the now deduplicated command was executed in the past - it had its own context!
CREATE TABLE history ( id text primary key, timestamp integer not null, duration integer not null, exit integer not null, command text not null, cwd text not null, session text not null, hostname text not null, deleted_at integer,
unique(timestamp, cwd, command) ); CREATE INDEX idx_history_timestamp on history(timestamp); CREATE INDEX idx_history_command on history(command); CREATE INDEX idx_history_command_timestamp on history( command, timestamp );
It's not just commands that are actual for the current session (like ls/cd/cat), it's also incorrect commands or just commands not worth retaining still being saved among with the useful commands.
The most precious is user's time. And when you fzf part of the command with the regularly saved history and would like to re-execute something important - you'll first get a long list that you'll first have to filter to find the command you were seeking.
So to counter your question with another: why store garbage?
Also, when I do want to reference my deep history I often find that seeing the full list of what I was doing is helpful at getting myself back into the frame of mind I was in when I ran the commands originally, which can be more valuable than seeing exactly which commands I ran.
Then why write history at all? Just discard it.
Maybe 3 in every 1k of my command lines is noise. Finding anything useful in there takes effort, so I rarely use anything older than a few days.