-
My most used bash commands
Shell history can tell a lot about its owner. What’s in your shell?
history | awk '{CMD[$2]++;count++;} END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a;}' | grep -v "./" | column -c3 -s " " -t | sort -nr | nl | head -n10 1 580 38.0328% git # I keep everything under VCS 2 202 13.2459% cd # Moving around a lot 3 171 11.2131% vi # Favorite text editor 4 127 8.32787% ls # I'm a curious person 5 43 2.81967% rm # I also like when it's clean 6 26 1.70492% usrswitch # https://gist.github.com/ruslanosipov/5453510 7 25 1.63934% exit # I don't like hitting the red cross button 8 18 1.18033% source # Reloading bash configuration files 9 17 1.11475% clear # Like when it's *really* clean 10 15 0.983607% gitk # Sometimes it is too messy for git log
-
Colorless week results
A round-up of The Week Without Colorful Prompt.
I worked with the colors disabled in bash, git, and vim for a week. So how did it go? It is definitely an interesting experience, but such a harsh change that it doesn’t really work out with everything.
Bash
Disabling colorful PS1 and removing color output for ls commands forced me to concentrate more on the actual text, changing the perception of the general bash workflow. I was more concentrated on the task, missed less details, and generally paid more attention to the output.
Git
Never repeat my mistake by disabling colors for git diff. Log and status are fairly easy to read, but the disabling of colors noticeably slows down the workflow.
Vim
Vim without code highlight forces you to remember your code structure more effectively, which is a great thing. Not having a need to rely on color can hint that a programmer has better understanding of the code he/she is writing.
Now that the experiment is over I have mostly returned to using colorful prompt. But I do turn syntax highlight off once in a while - it allows you to see problems from new angle and work more efficiently at finding a solution. Try it and see for yourself!
-
A week without colorful prompt
I noticed that I rely on colors in the bash terminal a lot, as in git output, diffs, directory and file listings… It gets worse when using vim - I feel lost without the cozy syntax highlight guidance.
Time to stop using output colors for a week whether in shell, git, or vim, and use only plain text with no fancy colors. Set git config –global color.ui false and don’t use –color flags in shell. Also, set syntax off and set a simple color scheme for vim.
What can I gain from all this? It will definitely reduce my productivity for a few days. However, I have a hint of an idea that changing the visual code representation will give me new insight on what I am currently writing.
Link to related commit on GutHub.
Check back in a week to see how it went!
-
Editing bash command in vim
You can open the current command you are typing for editing in your default text editor by pressing
Ctrl + x + e
. It will be executed after you write and quit the file. This is perfect for editing long/multi-line commands where typos are likely to occur. Consider something like this:for run in {1..10} do echo "Print me ten times" done
Editing this in vim is much more satisfying, isn’t it?
You can also open the last executed command for editing if you execute the
fc
command. You can also edit the last command starting with a certain pattern usingfc [pattern]
(you can skip the editor and execute the output offc
by adding the-s
option, and a useful tip is to havealias r="fc -s"
, which would allow you to execute the last command starting with “cc” by runningr cc
).P.S: In order for this trick to open
vim
and not any other editor, make sure you have the lineEDITOR=vim
in your~/.bashrc
. Obviously this works with any text editor. -
Vim, pathogen and git submodules
This is a step by step tutorial on how to organize your vim config files using git, pathogen, and git submodules. This tutorial assumes that you are familiar with git basics, but you don’t really need to understand every step in order to follow it. For simplicity, only
.vim
directory is a repository in this example. You may want to have all your dotfiles under version control and use a script to symlink files to the home directory. For example see https://github.com/ruslanosipov/dotfiles.Setting up
Let’s assume your
.vim
directory is a mess and is not under revision control. Let’s initialize a repository.cd ~/.vim git init git remote add origin git@github.com:user/project.git
Now let’s create
.vim/bundle
directory and clonepathogen
plugin as a submodule.mkdir bundle cd bundle git submodule add git@github.cfm:tpope/vim-pathogen.git bundle/vim-pathogen
Pre-pend the following code to your
~/.vimrc
to load pathogen from non-default directory:runtime bundle/vim-pathogen/autoload/pathogen.vim execute pathogen#infect()
Let’s add some more plugins as git submodules, for example:
git submodule add git@github.com:Lokaltog/vim-easymotion.git bundle/vim-easymotion
Now we can add and commit everything and push it to a repository.
git add . git commit -m "Use pathogen to keep track of vim plugins" git push origin master
Deploying
Assuming that your repository is located at
git@github.com:user/project.git
:cd ~ git clone git@github.com:user/project.git .vim
And you are done, all plugins are downloaded from their repositories now.
Maintaining
Git submodules keep track of specific commits and are not being automatically updated when target repositories have new commits. In order to update plugins you have:
cd ~/.vim git submodule foreach git pull git add bundle git commit -m "Updated all the plugins in a bundle" git push origin master
You probably want to make sure that new versions of plugins are compatible with each other before committing, however.