Raim

Once again I missed the expiry date of one of the SSL certificates on my server. Therefore I am now using a cronjob to warn me early enough that a certificate is about to expire.

This is the script /usr/local/bin/ssl-cert-check which checks the expiry date of the certificate files passed as arguments:

#!/bin/bash

DAYS=30

for file in "$@"; do
    openssl x509 -checkend $(( 86400 * $DAYS )) -in "$file" > /dev/null
    if [ $? != 0 ]; then
        echo "==> Certificate $file is about to expire soon:"
        openssl x509 -enddate -in "$file" -noout
    fi
done

And the corresponding cronjob entry checking SSL certificates once a day:

6       6    * * *   root   /usr/local/bin/ssl-cert-check /etc/apache2/ssl/*.crt /etc/ssl/certs/dovecot.pem

What is this?

I prefer IRC as communication protocol for multi-user chat and instant messaging. To keep in contact with users of other protocols/clients I use BitlBee which is a gateway connecting other chat networks like Jabber/XMPP and ICQ to your own IRC server.

Read more…

I wrote a bash script to create new pastes on pastie.org. It features automatic source language selection based on the file extension and has a switch to make a private paste.

$ pastie --help
Usage: pastie [options] [files...]

Options:
    -h, --help          display this help
    -l, --lang    set language of the paste
    -p, --private       make paste private

If --lang is not specified, this script will try to determine the type of each
file automatically based on the extension. If no files are given on the
command line it reads from standard input.

You can download it here:
http://pastie.org/904797

The script is public domain, so do whatever you want with it.

Although this is the initial release, I bumped the version number to 1.6 already. During testing the script I pasted itself several times to pastie.org. I set a arbitrary higher version number to avoid confusion in case the previous pastes ever turn up in Google or wherever.

Update:
Seems like their parser for shell is a bit broken and doubles the heredoc starting and ending sequences in the output. For whatever reason it appears as “<<END<<END”. Please use the raw version for download instead of copy & paste.

More than one time I wanted to sum up numbers in the shell.

Imagine a command producing a list of numbers like this:


$ ...
42
23
966
1764
529
4711


Now calculating the sum of these numbers is not trivial. Using tools like bc or calc directly is not possible because you would need to put plus signs between the numbers first. So you could probably replace all ‘\n’ with ‘+’ with tr — but not the last one as that would lead to a syntax error later. Or as an alternative you could write a long shell construct with while read ... etc. In short this is just getting way too complicated for such a simple task.

Here is the simple solution in awk:


$ ... | awk 'BEGIN {total = 0} {total += $1} END {print total}'
8035


Sometimes I was a bit frustrated that bzr does not support hunk splitting during selection changes with bzr shelve, as does git commit --interactive. Now with bzr 2.1.0 there is a new option available to launch an external editor to shelve changes as you like.

Just add the option change_editor to your ~/.bazaar/bazaar.conf in the [DEFAULT] section.

For example:


[DEFAULT]
change_editor = vimdiff -f @new_path @old_path

Alternatively, you can of course use meld or kdiff3 as well as change_editor, which will be a lot easier to use for beginners.

The placeholder @new_path will automatically be replaced with the path of the new version and @old_path with the path of the old version. With this configuration, there will be a new choice “e” during shelve:

...
Shelve? [yNefq?]

Entering “e” will start vimdiff in a two column view with the new version to the left and the old version to the right. You should read :help diff in vim to get more information about this mode. Basically you can obtain changes from the other buffer using do (“diff obtain”) and put changes to the other buffer using dp (“diff put”). Note that the old version on the right will be read-only and you are not supposed to change it. Also do not make unrelated changes or introduce new differences as that will result in conflicts on bzr unshelve later.

When you are fine with the changes exit the editor with :wqa. After confirming the shelve once more, you will see the left file as the new version in the working tree and every difference to the right file will be shelved.

Unfortunately this is not yet documented in bzr itself at the time of this writing.

Many people I know are using git as VCS and like it a lot. Although I used git in the past and still use it from time for time for some open source stuff, I was never a part of the hype on promoting git and bashing bzr.

Instead, after too much struggling with git, I totally turned to bzr now. Why? Now that’s what this post is about.

Read more…

Usually bash displays /etc/motd at the time of last login on opening a new shell. I do not find that information very useful, as I am opening new shells a lot, so the time does not really mean anything for me. Also, the MOTD rarely changes.

There is a feature in bash to hide these messages by creating a file ~/.hushlogin. This will make bash jump right to the first prompt without any output before.

But just in case the MOTD changes and includes important messages, I enhanced this setup a little bit. Instead of just touching the .hushlogin file, I am storing the old MOTD in it. At startup the old and current MOTD is compared against each other and will be displayed only if it differs. To avoid accidentally missing the MOTD, bash will also ask for my confirmation that I have read it.

Here is the snippet from my ~/.bashrc:

# Show motd only if necessary
cmp -s $HOME/.hushlogin /etc/motd
if [ $? != 0 ]; then
    echo -e "\n==> !!! IMPORTANT: /etc/motd changed !!! <==\n"
    cat /etc/motd
    echo -e "\n==> !!! IMPORTANT: /etc/motd changed !!! <==\n"
    read -e -n 1 -p "Show again? (Y/n) " ans
    if [ "$ans" == "n" ]; then
        cat /etc/motd > $HOME/.hushlogin
    fi
fi

Please note: If you are going to use this, make sure it will not get executed on non-interactive shells. Otherwise it can break tools like scp, sftp or rsync. To ensure this will not be used on non-interactive shells, I am using this conditional at the top of my ~/.bashrc:

if [[ $- != *i* ]] ; then
    # Shell is non-interactive.  Be done now!
    return
fi

Subversion allows to use a custom command for displaying diffs using svn diff --diff-cmd <cmd>. I have been using diff-cmd=colordiff in my ~/.subversion/config for quite some time now. This is really useful, but occasionally I would also like to use vimdiff to get a nice side-by-side diff.

Although this sounds quite easy at first, there are some hurdles. Subversion expects the given command to adhere to the GNU diff parameters, that means it expects it to understand and parse the labels it passes before the actual filenames. This works fine for colordiff, but not vimdiff which only wants the old and new filenames.

For a better diff experience with svn, I set up the following shell function which let’s me choose the program I want to use for diffing.

First, I need a new wrapper script at ~/libexec/svndiff which takes the actual diff program as first option, ignores the GNU diff labels and calls that program passing old and new filename.

#!/bin/bash
BIN=$1
shift 5
$BIN "$@"

Then I define this shell alias in my ~/.bashrc to extend the functionality of the svn command:

function svn() {
    case "$1" in
        diff-plain)
            shift;
            `which svn` diff --diff-cmd diff $@
            ;;
        diff-color)
            shift;
            `which svn` diff --diff-cmd colordiff $@
            ;;
        diff-vim)
            shift;
            `which svn` diff --diff-cmd $HOME/libexec/svndiff -x vimdiff $@
            ;;
        diff-filemerge)
            shift;
            `which svn` diff --diff-cmd $HOME/libexec/svndiff -x opendiff $@
            ;;
        *)
            `which svn` $@
            ;;
    esac
}

Now I can choose the program I find best suited for the current task in a very simplified manner, for example svn diff-vim -c1337.

X-Chat Aqua is a very nice IRC client for Mac OS X, but the latest version for download on their website is way out of date and a few years old.

X-Chat Aqua screenshot

A while ago libc volunteered to import the old CVS into a new SVN repository and started development on it again. So the version in SVN is now based on xchat 2.8.x, but there are still no binaries available.

Therefore I just put together my own build and I am also offering it as a download for everyone. The application bundle contains an Universal binary for both PowerPC and x86, while I was only able to test them on Leopard.

Additionally, I also replaced the default X-Chat icon with a modern one provided by Ryan Fernandez.

Download X-Chat Aqua: xchataqua-2009-01-21.tar.gz

$ history|awk '{print $2}'|sort |uniq -c|sort -rn|head
1134 vim
791 make
516 port
508 svn
305 sudo
283 cd
127 la
124 man
116 wcgrep
103 ./lcs-bottom-up

Read more…