81–90 of 198 posts
The problem I see is that if I ssh into 5 different remote hosts in a day, most of the commands are not executed on my host and thus not part of the local (or shared, distributed) history. I suppose this could be solved with either: - Some kind of modified ssh that sends back the commands to my host - Some kind of smart terminal that can analyze commands to build up the history Any ideas on how to practically solve t…
Earlier quoted context omitted.
At 0.5GB that's 5k per entry -- what are you storing for each? For comparison, my (non-work) history since 2012 (plain text) is 181k entries, and takes 25MB. I store the command along with when and where you ran it. ( https://www.jefftk.com/p/logging-shell-history-in-zsh )
Not defending the idea of a db history but no db schema is going to beat plain text's 1 byte 0x0A per line delimiter.
The problem I see is that if I ssh into 5 different remote hosts in a day, most of the commands are not executed on my host and thus not part of the local (or shared, distributed) history. I suppose this could be solved with either: - Some kind of modified ssh that sends back the commands to my host - Some kind of smart terminal that can analyze commands to build up the history Any ideas on how to practically solve t…
I made a script that uses atuin to get previous commands related to your current command line - latest commands ran in the same session, in the same directory, in other sessions, latest commands for the same executable etc. then feeds it into GPT and streams the replies to fzf so you can choose the best autocompletion (or it can fix problems in the line you've written already as well). On Wezterm and Kitty it can als…
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.
Why put effort into removing them? They use a trivial amount of disk space.
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?
Edit: apparently, they made it possible to disable that behavior and the documentation is much better
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.
During search, we do remove duplicates. It's not a bad idea though and I'll see how we can support it
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).
I have been using sqlite database since 2017 [1], has over 100,000 items in the database at this point. The database is almost 0.5GB, but I also use Full-Text-Search capabilities of sqlite. 2 years ago I have built a mac application [2], that syncs items via iCloud, and it only works on the macOS. I would highly recommend anyone who spend a lot of time in terminal to improve their shell history by using atuin or simi…
At 0.5GB that's 5k per entry -- what are you storing for each? For comparison, my (non-work) history since 2012 (plain text) is 181k entries, and takes 25MB. I store the command along with when and where you ran it. ( https://www.jefftk.com/p/logging-shell-history-in-zsh )
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.
With bash's HISTIGNORE, I can consciously prefix my command with a space to prevent it being added to history. 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…
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 :'(
Earlier quoted context omitted.
During search, we do remove duplicates. It's not a bad idea though and I'll see how we can support it
This is also sub-optimal, as it causes another problem: some of the commands are part of a bigger sequence (the most import property here is that items inside sequences are ordered, the order of commands matters!), so by blindly deleting duplicates - you break sequences. 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 sav…
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