on
(Almost) Every Single Shell Command I've Used Since 2017
Ever since 2016, I started keeping track of my dotfiles.
In my dotfiles, I had configured my ~/.bash_history
file to keep an unlimited number of lines of history.
Sometime in 2017, I reformatted my laptop and didn't think to backup my ~/.bash_history
. As such, my ~/.bash_history
file only contains data after Thursday, 13 April 2017 that were executed on my Ubuntu partition.
How I did it
I exported the following variables in my shell:
# Ignore commands that start with spaces and duplicates
export HISTCONTROL=ignoreboth
# Increase the maximum number of lines of history
# persisted in the Bash history file (default value is 500)
# Undocumented feature which sets the size to "unlimited".
# http://stackoverflow.com/questions/9457233/unlimited-bash-history
# ---------------------
# HISTFILESIZE: number of lines in the history file
export HISTFILESIZE=
# HISTSIZE: the number of entries in the history file
export HISTSIZE=
# Don't add certain commands to the history file
export HISTIGNORE='&:[bf]g:c:clear:history:exit:q:pwd:* --help'
# Add timestamps
export HISTTIMEFORMAT='%Y-%m-%d %H:%M.%S | '
# Force prompt to write history after every command.
# http://superuser.com/questions/20900/bash-history-loss
export PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
Then set these shell options:
# Save all lines of a multiple-line command in the same history entry
shopt -s cmdhist
# Append to the history file rather then overwriting it
shopt -s histappend
Things this does not track
This does not include other computers that I used during this time. These computers were excluded for obvious reasons—what happens at the office stays at the office:
- The laptop I used while interning at TextNow: accounts for 4 months of full-time work
- The laptop I used while interning at Tesla: accounts for 4 months of full-time work
- The desktop I used while interning at NVIDIA: accounts for 8 months of full-time work
In addition, the following are not included:
- Commands used in a
vagrant
box: synchronizing the~/.bash_history
file on the Guest OS with the~/.bash_history
file on my Host OS would be a pain - Commands used in a
ssh
session: I did most of my CS assignmentsssh
'd into the undergrad Linux servers after second year. I no longer havessh
access, so that data can't be retrieved - Commands used in WSL: I tried using WSL for about a year, but for some reason my Windows installation always seemed slower than booting into Ubuntu.
At the time, I was concerned that the size of my ~/.bash_history
file would balloon and take up all my space, resulting in my computer slowing down. Currently, my ~/.bash_history
file is sitting at roughly 2 MB
, which is practically nothing.
→ [email protected] (master) $ ll ~/.bash_history
-rw------- 1 karl 2.1M May 31 01:33 /home/karl/.bash_history
Even if we assume that 90% of the work I did in the past 2 years was on machines that this data doesn't include (which seems reasonable), that's still 20 MB
.
Top 20 Commands
I'm not really surprised by the Top 20 commands. They're all commands I regularly use as part of my workflow.
I use git
for all my side projects and assignments. I did try out Mercurial for a bit, but I found that GitHub's integrations and our school's GitLab instance were too useful to give up. Plus, most courses required us submit via Git (if we weren't using the custom submit
scripts that were on the undergrad servers). git
commands are also used quite frequently—to add files, checkout branches, clone repositories, etc.—so if I think about it, it isn't too unreasonable for it to be so commonly used.
vim
is my editor of choice, so that isn't really a surprise either. I suppose once I open up vim
in a directory, I typically just use fzf
and :e
to open files (and NERDTree
).
ll
is one of those commands I reflexively type whenever I cd
into a new directory. It's gotten to the point that when I use someone else's laptop, if they don't have ll
aliased, I'll alias it in that shell:
alias ll='ls -lha'
It's like this old habit I used to have where I would reflexively hit the Windows key when thinking. That took a while to break, but I think I'm mostly over that now.
I do most of my scripting in Python, as well as practice for interviews and any prototyping.
make
and vagrant
are probably so high up due to my work on Midnight Sun. Plus, I generally like having a Makefile
so I remember how to build a project I haven't touched in a while. We used vagrant
on the team to provision development environments, so that we would only have to support 1 (virtualized) configuration, and allow people to Bring Your Own Editor. I think it's worked out pretty well so far.
I discovered rg
sometime in 2017, after which grep
fell out of favour.
I am surprised, though, that cantools
made it into the Top 20, since I started using it this year. I guess my testing as a contributor, coupled with the DBC migration that I kicked off, resulted in this being used more often.
Commands that I sudo the most
apt-get
and apt
make sense. I know technically I should be using apt
now, but it's a hard habit to break.
This past year, I worked a lot with SocketCAN, and so a lot of it was me running:
sudo modprobe can
sudo modprobe vcan
sudo modprobe can_raw
Eventually I got sick of doing this and wrote a giant &&
'd version of those 3.
That's also why ip
is up there—SocketCAN is configured using netlink
sockets.
I used ifconfig
a lot when developing a Go-SocketCAN bridge for the Tritium CAN-Ethernet Bridge (tritiumbridgetools
), in order to debug why multicast UDP routing wasn't working, as well as just general testing throughout that process. That, tcpdump
, and tcpreplay
were my tools of choice.
Before I added a udev
rule, I needed to use sudo
to access a serial device via minicom
.
I also started playing around with Docker, but due to my lack of disk space on my laptop, my usage is rather limited—although, it's not really an excuse anymore, as apparently a Crucial 960 GB
SSD is now only $109.99.
Other than that, I guess most of these are fairly standard.
git operations
Here are all the git
commands I used.
Nothing too surprising here.
git st
is my alias forgit status
git ci
is my alias forgit commit -v
git co
is my alias forgit checkout
git ap
is my alias forgit add --patch
git aa
is my alias forgit add --all