Changing Directories Quickly in Linux

For the past few months I have been keeping track of the commands I use very frequently using the following command:
awk '{print $1}' ~/.bash_history | sort | uniq -c | sort -n | tail -5
The command 'cd' always shows up in the output. I am a developer, the number of directories I visit most frequently are my git repository  root, 3 more directories inside the repo (the components I work most frequently), logs directory and tests directory for running tests. I wanted to figure out a quick way to jump between these directories.

I found the following post useful in finding the solution to my problem:
http://unix.stackexchange.com/questions/31161/quick-directory-navigation-in-the-terminal

The commands that helped me for this are pushd, dirs -v, the ability to refer to a directory as
'~<num>' where <num> is the number against the directory in 'dirs -v' output.
Idea is to pre-populate the list of directories every-time I start a terminal.
I don't want the order of this list to change, so that over time the number of times I will need to execute 'dirs -v' reduces because I remember the corresponding <num> for these directories.
I saved the list as follows in .bash_dirs file in my home directory.


pushd -n /home/pranithk/.scripts > /dev/null
pushd -n /usr/local/var/log/glusterfs/bricks > /dev/null
pushd -n /usr/local/var/log/glusterfs/ > /dev/null
pushd -n /var/lib/glusterd > /dev/null
pushd -n /home/pranithk/workspace/gluster-tests/afr > /dev/null
pushd -n /home/pranithk/workspace/gerrit-repo/tests/bugs > /dev/null
pushd -n /home/pranithk/workspace/gerrit-repo/libglusterfs/src/ > /dev/null
pushd -n /home/pranithk/workspace/gerrit-repo/xlators/mgmt/glusterd/src/ > /dev/null
pushd -n /home/pranithk/workspace/gerrit-repo/xlators/cluster/afr/src/ > /dev/null
pushd -n /home/pranithk/workspace/gerrit-repo/ > /dev/null

I added the following lines in my .bashrc file to load it every time the terminal is started.

if [ -f ~/.bash_dirs ]; then

        . ~/.bash_dirs

fi

Now every time I start the terminal I have the directories already populated as below:

~

10:22:44 :) ⚡ dirs -v

 0  ~

 1  ~/workspace/gerrit-repo/

 2  ~/workspace/gerrit-repo/xlators/cluster/afr/src/

 3  ~/workspace/gerrit-repo/xlators/mgmt/glusterd/src/

 4  ~/workspace/gerrit-repo/libglusterfs/src/

 5  ~/workspace/gerrit-repo/tests/bugs

 6  ~/workspace/gluster-tests/afr

 7  /var/lib/glusterd

 8  /usr/local/var/log/glusterfs/

 9  /usr/local/var/log/glusterfs/bricks

10  ~/.scripts

Note that the number '0' is always associated with the present directory. The order of the directories is in reverse order of the list we have in the file because pushd keeps recently pushed directory first.

~ 

10:26:33 :) ⚡ cd ~8

/usr/local/var/log/glusterfs 

10:26:36 :) ⚡ cd ~1

~/workspace/gerrit-repo (master)

10:26:39 :) ⚡ 

As shown above if I want to change to my logs directory all I need to type is 'cd ~8', if I want to change to my git repository root I type 'cd ~1'. So much typing and excessive pressing of 'tab' are saved :-).

Have fun and enjoy.

2 Regressions in 3days

In the last 3 days 2 really bad regressions I introduced into afr were found :-(. This is not the first time I introduced regressions, I did introduce some before because I did not have the complete picture. I felt that I can reduce them as I learn more about the product. This time it is different, I have seen the second regression in my Unit testing. I assumed it is because I enabled stat-prefetch, disabling it made the test pass, but I did not realize that the test passed because the inode the fop happened belongs to different graph and it does not have split-brain flag. I could have avoided this if I had automated that test case.This made me feel pretty bad. After being frustrated with myself for a day I decided to reduce the probability of introducing regressions in the future.

This is my plan to minimize the regressions in future:
1) Every commit I make from now on is going to have 3 things in the comments:
*) RCA: Description of the reason for the bug.
*) Fix: What changes did  I introduce that would fix the issue.
*) Testcases: url to the test cases/ automated scripts I used for testing.
*) If a test is automatable I should do that without fail, no excuses.

In the code-review my colleagues can point out if I have missed any testcases.
Automation should make sure I don't introduce bugs while porting the fixes to other branches. Lets see how this approach goes.