Heipei

When I was younger I hated the summer (or let’s say I preferred winter). That was because in winter you had a reasonable explanation why you would sit in front of your PC all day long instead of going outside to play with the other kids or generally to “get some fresh air”. Now that I don’t have to explain myself to anyone anymore and that I’m bound to a desk by my studies and my work (and my hobbies as well) I can’t wait to prescribe myself a lot of fresh air. Having said that I’ll post a few pictures (the sky may already be blue, but don’t let that fool you) for those of you who couldn’t make anything of the last few posts here ;)

OK, I can already hear you saying “here we go again”. Well, I’m sorry that I’m not really in the mood to report much on my personal life (though, rest assured, everything is really going smooth, so don’t worry). Maybe this blog will undergo certain changes in the near future, but right now I’m not at liberty to discuss this (just wait a few more weeks).

For today I’ve got two small tips for you. The first is about printing directly from mutt (not that I print mails that often). If you’re not satisfied with the default output you can use a2ps (which has many other uses as well!) to produce a more readable output. To do that simply place this into your .muttrc:set print_command="a2ps -r --columns=2 -j -B|lpr" This of course assumes that you can use lpr to print on your system (which is my preferred way of printing stuff).

The next tip builds on my previous post about a zsh prompt showing the current branch if inside a git repo. Instead of just showing the branch-name we want to indicate whether the working directory is clean or if it has uncommitted changes. With git there are two kinds of “dirty” though: changes in the index but not committed and changes not in the index. So we have two indicators, which makes the whole thing look like the image. Red is changes not in index, and green is changes already added to the index. The code you’re gonna need in your .zshrc looks like this:

# Set a nice git-prompt (calls git_status())
git_prompt_info() {
  local git_dir ref br;
  git_dir=$(git rev-parse --git-dir 2> /dev/null) || return
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  branch_prompt=${ref#refs/heads/}
  if [ -n "$branch_prompt" ]; then
    status_icon=$(git_status)
    echo "$status_icon%{$fg[yellow]%} [$branch_prompt]"
  fi
}
# Show character if index and/or work-tree are dirty
git_status() {
  my_status=$(git status)

  if [[ "$my_status" == *"Changes to be committed"* ]]; then
    output="%{$fg[green]%}+"
  fi
  
  if [[ "$my_status" == *"Changed but not updated"* ]]; then
    output="$output%{$fg[red]%}*"
  fi

  echo $output
}

Now all you’ve gotta do is call $(git_prompt_info) somewhere in your RPS1.

Up until right now I’ve been using xterm. While it’s not the best of terms it does support 256 colors out of the box (and I don’t use fancy stuff like transparency/translucency). What it has been lacking however, and which Flo pointed out, was the support to make URLs clickable. This is an important feature, especially since I use mutt and slrn regularly, and my IRC-client is irssi, so the majority of links I’m interested in arrives in my terminal.

So I went looking for a term with clickable urls but also with 256-color-support and found rxvt-unicode (or short: urxvt), which is a fork of the original rxvt with unicode-support (duh!). To get 256 colors working you have to apply the urxvt-8.2-256color.patch in the doc subdirectory of the source.

`Up until right now I’ve been using xterm. While it’s not the best of terms it does support 256 colors out of the box (and I don’t use fancy stuff like transparency/translucency). What it has been lacking however, and which Flo pointed out, was the support to make URLs clickable. This is an important feature, especially since I use mutt and slrn regularly, and my IRC-client is irssi, so the majority of links I’m interested in arrives in my terminal.

So I went looking for a term with clickable urls but also with 256-color-support and found rxvt-unicode (or short: urxvt), which is a fork of the original rxvt with unicode-support (duh!). To get 256 colors working you have to apply the urxvt-8.2-256color.patch in the doc subdirectory of the source.

`

To configure urxvt you can conveniently use your ~/.Xdefaults. Mine looks like this:

``Up until right now I’ve been using xterm. While it’s not the best of terms it does support 256 colors out of the box (and I don’t use fancy stuff like transparency/translucency). What it has been lacking however, and which Flo pointed out, was the support to make URLs clickable. This is an important feature, especially since I use mutt and slrn regularly, and my IRC-client is irssi, so the majority of links I’m interested in arrives in my terminal.

So I went looking for a term with clickable urls but also with 256-color-support and found rxvt-unicode (or short: urxvt), which is a fork of the original rxvt with unicode-support (duh!). To get 256 colors working you have to apply the urxvt-8.2-256color.patch in the doc subdirectory of the source.

`Up until right now I’ve been using xterm. While it’s not the best of terms it does support 256 colors out of the box (and I don’t use fancy stuff like transparency/translucency). What it has been lacking however, and which Flo pointed out, was the support to make URLs clickable. This is an important feature, especially since I use mutt and slrn regularly, and my IRC-client is irssi, so the majority of links I’m interested in arrives in my terminal.

So I went looking for a term with clickable urls but also with 256-color-support and found rxvt-unicode (or short: urxvt), which is a fork of the original rxvt with unicode-support (duh!). To get 256 colors working you have to apply the urxvt-8.2-256color.patch in the doc subdirectory of the source.

`

To configure urxvt you can conveniently use your ~/.Xdefaults. Mine looks like this:

``

The nice side-effect is that urxvt is about 10 times faster than xterm (try it by cat-ing a large file and using ‘time’ to measure it).

I use git to version almost everything I work with on a daily basis. My emails reside on an IMAP-server and my bookmarks are on delicious. My config files are written such that the same file can be used on any machine I have. The question remains how to keep all of the other stuff in sync.

There are excellent backup-solutions (and you can easily write your own), there’s git for version-control and of course there is rsync, but often you wan’t something else. Obviously you don’t want to put big files that can’t be efficiently compressed into a git repo (making it twice as big) and then push/pull multiple repos everytime you changed one file on one host. rsync also has a few drawbacks.

Enter Unison. Unison can best be described as a bi-directional rsync with a nice GUI which can be started from one host. The problem with just using rsync is that when you sync you effectively designate one host as master and the other one as the one that should be overwritten if needed. The user interface leaves much to be desired as well. I use rsync mostly for unsupervised backups.

Unison solves all of these problems. It works with profiles, where local and remote paths are specified and ignore masks can be set. Then when started on a profile it checks the paths, and gives you pretty good settings to sync it (obviously if a file is changed you probably want the newer one on both hosts, and if a file was deleted but was there before, you probably want to delete it on the other host as well). You can then go through the file list and use keyboard shortcuts to mark files as use-local, use-remote, skip for this sync and ignore permanently. It may not sound that spectacular, but that is exactly what sets Unison apart. So, if you work on more than one host give it a try, it works on Windows, Linux and Mac OS X.