🇵🇹 Versão em português deste texto aqui! 🇧🇷
I don't know about other people, but I love having a docker development environment. Being able to just run a docker container with all the dependencies taken care of for all projects, handling versions and etc is just too good.
But what I don't love is when I exit the container and later start it again to realize I have lost all the previous commands, so I can neither
ctrl+P to find them. Sad times!
So I decided to try to keep this history, and in order to figure out how to do that, I first thought, how does bash itself knows the previous commands?
It turns out there is an env var named
HISTFILE, which will contain a path to a text file with the bash history. Apparently, by default it is set to
OBS: If your container does not run bash, but rather some other shell, we would have to find out where this other shell puts its history file.
So a workaround I have found is to change this env var to somewhere else, somewhere inside the project's dir that I'm working on to avoid losing it after stopping the container.
Lets say that the docker image builds a
/app folder with all the contents of the directory of the project I'm working on inside it, I could set
/app/.bash_history, and if we map with a volume with the project's dir contents, I would have a persistent history of commands between docker sessions. The file name itself doesn't even have to be
.bash_history, it could be something like
/app/.docker_bash_history, for example.
To start a container with a specific variable, we can use the
docker exec -it -e HISTFILE=/app/.bash_history -v <volume> <...other stuff...>
If we are using Docker Compose, we could either pass an env file or the direct variables to it in the
docker-compose.yml (or other config file you may be using):
# example config file services: app: build: . volumes: - .:/app # mapping this volume to persist modifications to our new history file command: echo Hi! env_file: # we can define the variables inside the .env file - .env environment: # or we can pass them directly here HISTFILE: /app/.bash_history
A problem with this approach arises, though. I now have a new file in my project's root, a file that git will see, unless we put it in our
.gitignore, and I really think we should. I don't want to commit my history nor do I want to pull other people's history, because this would defeat the purpose of having a history file. Other than that, I just created a new file in the root, which could cause some noise and litter the root folder. Maybe you can find a better place other than the app's highest level folder.
And that's pretty much it. I don't know how bad or good of an idea this is, but I'm enjoying it so far. I created a
dotfiles/ folder inside the root that also has other dot files, like
.irbrc in a ruby project. In order to get it working, I had to put this in
require 'irb/ext/save-history' IRB.conf[:SAVE_HISTORY] = 10_000 IRB.conf[:HISTORY_FILE] = ENV['IRB_HISTFILE']
And then define not only
HISTFILE, but also
IRB_HISTFILE environment variables, like this:
HISTFILE=/app/dotfiles/.bash_history IRBRC=/app/dotfiles/.irbrc IRB_HISTFILE=/app/dotfiles/.irb_history
An important note on IRB, if you leave the
.irbrc file in the root folder, everytime you fire up IRB, it is going to use the project's
.irbrc, since it is the first found config file for IRB. This could be undesirable, though. In this case, putting the
.irbrc inside another directory, like
dotfiles/, becomes essential.
Thanks for reading! (: