teranex weblog


Posts with this tag appear also on the Inuits Planet (http://inuits.be/planet)

Vim: checking PHP code (and Python and...)

Do you hate it as much as I do when you are writing some PHP (or Python or whatever) code in your favorite editor, hit 'save', reload the page in the browser in the hopes that you will see the new most awesome feature you ever wrote, but instead you are greeted by an unfriendly PARSE_ERROR_YOU_FORGOT_A_CLOSING_BRACKET_YOU_STUPID-error? Right, it feels like you just built a rocket, but upon launch you discover you didn't foresee a doorknob and can't get in anymore...

Luckily, if you are using Vim there is a nice plugin to quickly catch these errors (and more). The plugin I'm talking about is Syntastic. The plugin is built as a generic framework to run and process the result of a syntax checker. The syntax checkers themselves are specific for each language. Most of the syntax checkers start an external syntax checker or linter and return the output to Syntastic, telling it how to parse it.

Belgian Vim user group for meetups

A while ago, after reading about some of the meetups organized by VimBerlin and VimLondon, I started wondering if there would be any interest in a similar group for Belgium / Antwerp. Today I asked the question on Twitter and I'd like to ask it here again:

Would there be any interest in a Belgian or Antwerp usergroup for Vim with regular meetups?

Since there are already some good communities for Vim online, such as the vim_use mailinglist, I don't want to start an online community. The idea would be to organize a meetup every once in a while. At first 2 or 3 months, to avoid rushing stuff. During such a meetups we can organize to have a few people give short (15 - 30 minutes) talks about a specific topic related to Vim. These talks can cover a very wide range of topics. such as:

SSH authentication with your PGP key

A few weeks ago I learned that a few of my colleagues were using PGP. I myself started using PGP around 2003, using the GnuPG implementation. However, since I didn't know many people who used it my usage slowly faded after a few years. In 2009 I shortly picked it up again by creating a new key to phase out SHA-1, but that was also of short duration. Thanks to my colleagues, I'm now starting to use GnuPG again. My key is still the same as created in 2009: 610DB834.

I noticed that both my PGP-key and my SSH-keys use the RSA-algorithm, so I started wondering whether it was possible to use my PGP-key to authenticate myself to SSH-servers. After some Googling it seemed possible, but not very straightforward. In the end I managed to get it working, thanks to the very friendly support of Werner Koch (the main developer of GnuPG). Since it is not very straightforward I will document my findings here for future reference.

Adding an authentication key

First add an authentication subkey to your PGP-key, as it is apparently a best practice to use subkeys for each type of usage. To do so you need to start gpg with the --expert flag like this:

# where 610DB834 is the id of my key
gpg --expert --edit-key 610DB834

When you are in gpg type addkey and type '8' to choose (8) RSA (set your own capabilities). This option let's you manually configure the new key. Then type (each time followed by enter): S, E, A, Q, so that it says 'Current allowed actions: Authenticate'. Then choose a keysize (I use 4096) and an expiration date (5 years from now for example) and wait for the key to be created. Finally save to save your key. Your authentication-subkey is now ready.

How I upgraded Budts.be to Drupal7. Part2

This is the second part of a series on how I upgraded my website from Drupal 6 to Drupal 7. The sources for my website are freely available on my github account.

Automating as much as possible

When I started working on the new version of the site, I did not only want to be able to install the site from scratch. I also wanted the one-time upgrade from Drupal 6 to Drupal 7 to be as smooth as possible. However, the life of a website doesn't stop once the initial deploy (or 're-deploy' in this case), is done. In fact, it only begins at that point. You will need to keep the site updated with new functionality and, more importantly, with security updates. Sadly, this deployment and updating is often an afterthought, or not done at all. Let's face it, deployment and updates are boring and a risky task. So I wanted a setup where I could as easily as possible deploy and update my site, without having to think much about it.

I have split up everything which needs to be done into a few simple steps and written scripts for it.

How I upgraded Budts.be to Drupal7. Part1

This is the first part of a series I plan to write on how I upgraded this site to Drupal 7. I have made all the sources available on my github account, as it can serve as an example on how to do Drupal development without database dumps. These are the parts I plan to write:

You can find the sources here: https://github.com/teranex/budts.be


Nearly 1,5 years ago I decided that I wanted to migrate my Wordpress blog and two other custom sites into a single Drupal based website. At that time Drupal 7 was not yet final (or just a few days, can't remember exactly) and was not yet really in a usable state for a regular site without too much difficulties. So I went with Drupal 6 and I decided to use the 'classic' method of Drupal development: database dumps. I figured that, since it was just for my personal site, it didn't really matter. For deployment I used rsync.

Drupal Development: some tools and utilities

I finally took the time to make my 'drupaldev'-repository available.

First a short introduction: It is my strong opinion that Drupal modules which are only used during development, such as devel, diff, etc, should never be deployed to production. They shouldn't even be in the repository. Instead, I keep a personal collection of development-modules in a separate repo. Thanks to the fact that Drupal recursively searches for modules inside the modules folder, I can simply create a symlink to my collection of development modules. This allows me to use my preferred modules, even though they are not in the repository for the project.

For Drupal7, I usually just create a symlink, named devmodules7, in sites/all/modules. Like this:

# from the drupal root of the project
ln -s ~/drupaldev/devmodules7 sites/all/modules/

The repository itself contains a collection of modules, for both Drupal 6 and Drupal 7, and some utility-scripts. After experimenting with copies of the modules and git submodules, I finally settled on drush make to manage the modules. Instead of copying all the modules in my repo, I only keep a make-file for each Drupal version (currently 6 & 7). This makes it really easy to update all the modules, as I can simply run the makefile again. To make this even easier I have added a build script which will run all the drush make-files with the correct arguments:


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.

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:


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:
    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':
    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:


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: