Programming, philosophy, pedaling.

Configuration for Fun and Profit

Feb 10, 2015     Tags: programming, workflow    

This post is at least a year old.

I’m a big fan of configuration files. A really big fan.

I configure so much that my older computers pause noticeably whenever I source ~/.bashrc, which is probably a problem.

Therefore, I’m going to share a few of my favorite (and less used) tools and aliases. Hopefully you, the reader, will find them useful and possibly incorporate them into your own configurations.

bind and xbindkeys

You’ve probably heard of these two, and probably even use them. However, you (probably) aren’t using them enough.

xbindkeys is terrific because it works seamlessly across every Linux distribution with an X server, which means no more fiddling with distro or desktop environment specific configurations. It also has a fairly sane configuration format that can be edited by hand, as well as a graphical utility for convenience.

My primary use for xbindkeys is an emulation of puush, one of the few programs I actually miss from Windows (but that’s another story). With a few short keybindings and a modified version of Joe Schillinger’s poomf.sh, I can upload both fullscreen and selection screenshots just like I did with puush.

bind is an equally amazing tool, although it is limited to GNU bash. Most shells have an analagous utility, so don’t worry if you aren’t a bash user (the syntax will probably differ, however). bind does for the terminal what xbindkeys does for X11 and, like xbindkeys, is entirely independent of the terminal emulator being used.

bind can either be used as a utility (called by the shell or the user) or loaded through ~/.inputrc. As a utility, its syntax looks something like this:

bind -x '"\C-o":echo foo' # -x for eXecute 'echo foo' on Control-o

I prefer the above form because I can use it in my ~/.bashrc, but the ~/.inputrc form is slightly cleaner:

Control-o: 'echo foo\n' # print 'echo foo\n' on Control-o (treated as a command due to '\n')

The primary difference with the latter is that the command is first echoed to the terminal, then executed due to the newline character. Without that ‘\n’, ‘echo foo’ would simply appear on the prompt.

I find this kind of binding most useful for those times when I “break” my terminal, either by cating a binary file or something equally stupid. Instead of killing the term and starting a new process, I simply have this in my ~/.bashrc:

alias ttyreset='echo -e \\033c' # ANSI reset code
bind -x '"\e[15~":ttyreset' # call ttyreset with Function-5

With those two set, all I have to do is hit F5 and my terminal is good as new.

Colorizing man

On most terminals and with most fonts, man’s italic and bolded fonts are barely distinguishable from the standard roman font. As a result, keywords that are supposed to be distinct are barely so:



Naturally, the solution is to colorize man’s output. While many solutions have been offered over the years, most either involve installing another pager (which is dumb) or changing terminal-specific settings (which is even dumber).

The best solution I’ve found is to take advantage of the LESS_TERMCAP_ environment variables, which can be used to modify the control codes used by less when parsing manual pages. Here’s how I do it, from ~/.bashrc:

function man()
  env \
  LESS_TERMCAP_mb=$(printf "\e[1;31m") \
  LESS_TERMCAP_md=$(printf "\e[1;31m") \
  LESS_TERMCAP_me=$(printf "\e[0m") \
  LESS_TERMCAP_se=$(printf "\e[0m") \
  LESS_TERMCAP_so=$(printf "\e[1;44;33m") \
  LESS_TERMCAP_ue=$(printf "\e[0m") \
  LESS_TERMCAP_us=$(printf "\e[1;32m") \
  man "$@"


much better.

In this solution, the LESS_TERMCAP_ variables are contained within the function via env, preventing any unintentional shell environment contamination. Of course, exporting these variables isn’t likely to cause any trouble anyways, so a function isn’t really necessary.

Tweaking the userland

Finally, the userland in general. Like most programmers using Linux or UNIX systems, I use dozens of command-line utilities a day coupled with countless flags and arguments. I (and most others) do this completely subconsciously, as a force of habit and repetition.

Here are some (mostly) tiny configuration files and aliases that can help cut down on that repetition:

curl (~/.curlrc) and wget (~/.wgetrc)

These two utilities, arguably the two most common for online downloading and scraping tasks, rarely have their configuration files taken advantage of.


progress-bar # replace the normal progress meter with a compact bar
user-agent = "Mozilla/5.0 Gecko" # override the user-agent sent to servers


robots = off # disobey the robot exclusion standard
timeout = 5 # time the connection out after 5 seconds of waiting
user_agent = "Mozilla/5.0 Gecko" # override the user-agent sent to servers

wget’s configuration options are much better documented than curl’s, although most of curl’s match the format of their equivalent flags.

chmod and git

If you use scripting languages on a regular basis, you might find yourself repeatedly chmodding files to set the executable bit. Similarly, if you’re administrating other users, you might find yourself giving your account read and/or write permissions on their files.

These aliases aren’t much to look at, but they save a few keystrokes:

alias +r='chmod +r'
alias +w='chmod +w'
alias +x='chmod +x'

Similarly, if you use git for source control and versioning, you might find yourself repeatedly typing the same add-commit-push cycle over and over again. These aliases shorten that cycle a little:

alias ga='git add'
alias gcm='git commit -m'
alias gp='git push'
# gco for git checkout, etc...

You could also put these aliases in git’s ~/.gitconfig, although this results in the slightly longer syntax of git <alias>.


I hope you’ve enjoyed (and possibly learned some things) from this post. It’s my first ever (real) blog post, and hopefully not my last. If I’ve made any mistakes or you have something to improve or contribute, don’t hesitate to tell me.

Thank you for reading!

- William