I’ve used distrobox more and more and am at the point where I need to start saving and integrating history differently. Or like, when I’m installing and building something complicated, I need to start saving that specific session’s history. I am curious what others might be doing and looking for simple advice and ideas.
You must log in or register to comment.
Been using this recently and it’s great. I have it on my Mac for work but I should really set it up on my personal Linux PC as well because I really like it.
My default is too use fish shell in all my machines. Never worried again about losing history.
I’m not worried about losing my history. I’m looking for a way to seamlessly create a dual history where the default is to have a unique history for each distrobox container with a way to integrate a full history from my primary terminal, likely with timestamps to switch back and forth. I can think of a couple of ways of doing this, but I wonder if others have explored already and found a better way.
Atuin, as others have said. It supports many shells and you can have server/client machines to sync your history.
I think this is the only change I’ve made that affects my history… It simply ignores multiple copies of a command when you repeat it multiple times, making it easier to up-arrow through the unique things I’ve executed.
export HISTCONTROL=ignoredups
I was originally worried this would dedupe the entire history file, eliminating occasionally useful historical context. Apparently from what I’ve read, it only compares it to the most recent entry in the history file. Might have to include this one too. Thanks
I only include it because pretty much every guide on zfs setups recommends disabling it these days. I don’t believe it’s anything I’ve every had to use despite several drive crashes over the years.
Reply to the wrong person? What does shell history have to do with zfs?
Heh sorry about that. There’s also a zfs conversation going on where I had suggested disabling the ‘dedup’ option. I’ve never heard of dedupe being used in the context of the shell history, so yeah, I got confused.
HISTSIZE=50000 HISTFILESIZE=200000 # Append history after every command export PROMPT_COMMAND='history -a'I can’t count on how many times in the past that I’ve had long running systems crash or OOM kill basically everything and I just lose my entire history for the week. Now I’m free to overtax my system as much as I want.
I have been pretty content with just zsh with fzf - extends the ctrl+R with interactive fuzzy search across the history.
In theory some session like behaviour should be easy to make with a little script that changes $HISTFILE
Just fzf + the same version control I use for my dotfiles. I have no interest in mixing machine histories like atuin offers, so that makes sense to me.
I haven’t used atuin yet, but I believe the histories from other machines is more like accessible than mixed - you don’t just hit ↑ on machine1 and see machine2 commands.
Maybe a little primitive, but I copy my .bash_history file to a folder with a dated name every afternoon using a cron job. Then I can just grep that for commands I know I ran in the past. ‘sort -fu’ will remove the duplicates in the results.
Genuine question, I see alot of people concerned by losing their shell history, any specific reason why?
I mean I keep mine to default and auto-delete every shell history after logout :/ And I never seemed bothered, I never go up more than 10 lines anyway… Whats the point/use case of keeping a whole shell history over time?
For me, it is not about “lost history.” It is about contextual history and knowing if some tool I built in a distrobox uses only dandified, pacman, aptitude, portage; or if it also uses venv, conda; or if there was some install script.
It would be nice if I was on a stable kernel to avoid such a dependency salad, but that is not within the scope of playing with the latest AI toys where new tools and exploring new spaces is constantly creating opportunities to explore.
It would be nice if I was some genius full stack dev that could easily normalized all the tools under a single dependency containerization scheme, but that is not within my mental scope or interests at the present. For most AI tools, I follow the example given and only add a distrobox container as an extra layer of dependency buffering from the host. The ability to lazily see the terminal history for each of those containers is a handy way to see exactly what I did months ago.
Thanks for your insight ! Even though I didn’t really get everything, but It seems there is a specific use case !
Maybe overtime with more experience I will get there and have a better understanding of what you meant with contextual history.
