I use a script to name each GNU screen session "projectA", "sysadmin", etc.
Then in my .bash_profile, I set the Bash history to be a separate file in my ~/.bash_hist_dir subdirectory.
if [ "x$SCREEN_SESSION_NAME" != "x" -a "x$WINDOW" != "x" ]; then
if [ ! -d ~/.bash_hist_dir ]; then
mkdir ~/.bash_hist_dir
fi
export HISTFILE=~/.bash_hist_dir/${SCREEN_SESSION_NAME}.${WINDOW}
fi
So each separate window in each session gets a unique history file.
I have up to 10 windows per GNU screen session, and sometimes 6 to 8 terminal tabs.
Each separate GNU screen window is used for specific things: "edit", "build", "debug", etc.
This all makes it easy to maintain the context of all the things I work on.
Oh, I see. I interpreted "context" as current working directory. I took a look at your .bashrc but I couldn't detemine any sort of partitioned history. Are you saying that you have something like a virtual environment (as in Python) and the bash command history is separated according to the environment?
90% of the time, the bash history is super relevant to the current context. A small amount of the time, I remember that I issued a command, but not in which directory - in these cases, I can just search the history directory, and get both the context of what the command was, and also where I was when I originally issued it.
I use a terminal multiplexer (happens to be screen, but could as easily be tmux) to manage local contexts. A fresh terminal in the same context is then just three keys away. The contexts drive a number of things, but most importantly I set BASH_HISTFILE so each has its own history. I love it, but of course ymmv.
I maintain almost all my bash history and I often use it to reconstruct a sequence of events in the past when I feel like maybe a mistake had been made.
Thank you!! Why on earth isn't that the default. It always seemed weird that with multiple bash windows open, the commands from most of them weren't added to the history.
AFAIK, it tracks its own history separately from other shells. It's not going to read .bash_history (or whatever) to discover your usage patterns - you'll have to use fish for awhile and build some history.
One thing that has helped me when moving back and forth between projects is to use screen (you may prefer tmux) to wrap up particular contexts, having my bashrc set things like my history file based on a single variable. Just keeping history from getting mixed up helps a lot, I find, but it also gives hooks for other bits of tweaking (aliases and such)
A thing to do with your environment setup, so a tool I suppose? There are probably different plugins out there for it. In my case it's a few lines in .bashrc that override the history processing to never delete old history, and add tags indicating which session wrote the command. This way I can reboot a computer, restart all 30 screen sessions, and have each access backward searchable history to the start of time (2013 for me).
I'm guessing newer shells may have better support for this kind of thing instead of running shell commands to wrangle text files on every prompt.
Splitting history is done fundamentally by setting HISTFILE - nothing too surprising about that.
But for my particular setup, I more broadly divide my shell use by context. I have a script called "session". `session $somename` looks for a screen (feel free to prefer tmux) session named $somename. If one exists, it attaches it. If not, it spawns it. Before doing so, it sets a shell variable SESSION to $somename. My bash_profile then customizes a lot of things based on the contents of that variable, including adding $SESSION to the prompt, and sourcing ~/.session/$SESSION/bash_profile. This lets me set context-specific aliases and such. Because SESSION is set above the terminal multiplexer, new windows spawned while in one context share the same context.
I've found most of this quite nice, but the history is the biggest win.
Heh. This is funny timing, as .bash_history made me feel like an idiot just yesterday morning.
I was sitting here between queries and I thought 'y'know, all I ever do with history is grep for things. I wonder what else I can do?' When I want to learn about something quick, I usually start with the built-in help; so I did
history --help
The built-in help for history, unfortunately, is woefully inadequate; this was the output:
history: usage: history [-c] [-d offset] [n] or history -awrn [filename] or history -ps arg [arg...]
I said to myself: "Hmm. Wonder what those do?" -- and in a moment of bash stupidity, I thought: "well, let's try it!"
history -c
There's no output from that command, but it didn't take long to figure out what it does. It deletes your entire bash history, clearing the history in RAM and emptying .bash_history.
Since I use history all the time, I panicked. Holy crap! What have I done? I spent a few minutes internalizing the obvious lesson that everybody knows - never run commands without knowing them first. Thankfully, though, I had another bash open at the time. And after I'd beaten myself up over it, I thought for a moment, jumped over to the other shell, and did:
cd && history | cut -c 8- >> .bash_history
... because (after all) the evil, evil history -c command doesn't kill the history from RAM in other shells.
I understand your comment. Intuitively I agree with you but in the context of one of the original devs writing bash it would make no sense to tie the history command to the interactive REPL. Treating everything the same would lead to less bugs in "their" system while leaving a caveat for all the userland script writers.
reply