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 xbindkeysYou’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:
1
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:
1
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:
1
2
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.
manOn 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:
ugh.
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:
1
2
3
4
5
6
7
8
9
10
11
12
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.
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.
~/.curlrc
1
2
progress-bar # replace the normal progress meter with a compact bar
user-agent = "Mozilla/5.0 Gecko" # override the user-agent sent to servers
~/.wgetrc
1
2
3
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 gitIf 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:
1
2
3
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:
1
2
3
4
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