xdg-open vs exo-open

While playing with XFCE (more on that later) I was searching for a tool equal to gnome-open. Gnome-open can be used under Gnome to open files etc in the preferred application. While Googling I found not one, but two tools in various blogposts and forum messages: xdg-open and exo-open. I tried both, and both did the trick.
So that left me wondering: what's the difference after the two? Googling didn't really give a useful answer.
Yesterday I found the answer, by accident: exo-open is the tool from XFCE to open files etc in your preferred application, similar to gnome-open, under Gnome, and kde-open under KDE. xdg-open is a shell-script which works independent from the desktop-environment. It will inspect your environment and if it can detect that you are running Gnome, KDE, XFCE or LXDE it will use the correct tool from your Desktop Environment (such as exo-open under XFCE). If it can't detect your environment it will try to open the file itself. So basically, if you know which Desktop Environment you are running, you can use the tools which comes with your DE. If you're uncertain, or you are writing a script which should work across different Desktop Environments, use xdg-open. Or simply always use xdg-open.

Talk: Git in Depth

I first created this presentation for the Drupal Camp 2011 in Kiev, but I have given it at a few other locations and conferences, such as LOADays 2012.

Since it is a talk about Git, the talk itself obviously is also version controlled with Git. Since I'm finally really tired with WYSIWYG presentation software (yes, even LibreOffice Impress), I tried something different. The slide show is written as a single markdown document, which is then converted using the nice S9 application. It uses the 'HTML5 Google rocks' template to give it a very cool and clean look.

My slides are available on my github account: https://github.com/teranex/git-talk and they are licensed under the Creative Commons BY-NC-SA 3.0 license.

My Bash prompt

A few days ago I took the time to finally rewrite the code for my Bash prompt. I had been using the prompt for nearly two years, but the code was fugly and had some problems. Now it runs without problems and is nicer so I can finally share it with the world. You can find the 'trexprompt' in my dotfiles repository on github. It also has a project page on this site with installation and configuration details. The prompt has the following features:

  • Shows the current path, trimmed in the middle for very long paths.
  • Shows the current load and time when last command finished on very wide terminals, right aligned.
  • When inside a Git repository, shows the current branch and state
  • Shows the exit code of the previous command when non-zero
  • Configurable colors (left and right)
  • When no colors are configured, colors will be calculated based on the hostname. So every host will automatically display other colors.

And a screenshot:

Screenshot

Getting Audex to rip into Ogg Vorbis

Audex is a really nice (KDE) application to rip Audio CDs. It can lookup the CD information (so most of the time you don't have to type all the tracktitles yourself), it also tries to fetch the correct cover (and succeeds most of the time) and has very flexible configuration settings. Sadly, the version in the Ubuntu (currently 0.72b1) repositories has a few problems when you want to encode your songs in Ogg Vorbis. Here is an overview of the problems I had and how I hacked my way around them (without recompiling Audex), so I can use Audex to rip my CDs to Ogg Vorbis.

The most important problem is that Audex simply doesn't detect the Ogg Vorbis encoder. As documented in this Debian bug report Audex passes an incorrect parameter to oggenc to detect the version. While it should pass -V (uppercase V) it passes -v (lowercase v). To 'fix' (read: hack) this I took the following steps:

  • First check that your have the Ogg Vorbis encoder (oggenc) installed. In Ubuntu you can install it from the repositories by installing the 'vorbis-tools' package:
    1
    
    sudo apt-get install vorbis-tools
  • Now you should have the Vorbis encoder in /usr/bin/oggenc. But Audex won't detect it because it will call it with an incorrect paramter. So to fix this I first renamed oggenc to 'oggenc_real':
    1
    
    sudo mv /usr/bin/oggenc /usr/bin/oggenc_real

My vim configuration on Github

Ever since I started using Vim as my preferred text editor I have been keeping my configuration under source control. At first I kept my config for all the various applications + some useful scripts in one Git repository. But after I had given a (very) short presentation at work, I started to think about splitting of my vim-configuration into a separate repository. I have already learned a lot of useful tricks and settings about vim by studying other peoples vimrc-files, so I feel like it's only fair to also put mine out in the wild.

So first I did a little Git magic to split of my vim subdirectory into a separate Git repository, without losing any of the history. The answer on how to do this can be found on StackOverflow: Detach subdirectory into separate Git repository.

Then I created a repository on Github and pushed my entire vim configuration. Feel free to explore it and use pieces from it. (Or use it in it's entirety, but I don't think that would really be useful)

Some 'cool' features I use in my vimrc:

Pathogen

A few weeks ago I started using the Pathogen-script for vim. This script makes it possible to keep every vim-plugin in it's own directory. To use Pathogen you need to call at least one of it's functions so it can do it's job. I choose to keep this initialization in a separate file from my vimrc-file. That is why my vimrc starts with the following line:

Redefining functions in Javascript

A few days ago I wanted to know how easy it is to redefine a function in Javascript which is already defined. I know that doing something similar in Ruby is rather easy and I had the feeling that it would be possible in Javascript as well.

After some googling and testing I came up with the following test document (which is perfectly valid HTML5 btw!):