Every now and then I get the 'prompt-itch' and then I need to tweak my prompt again :) Of course I'm very happy with the way my prompt was.

My idea of a good prompt is to be as short as possible and still be informative about your environment:

Only tell stuff I'm really interrested in and for the rest SHUT THE HELL UP!

So no date output in my prompt, If I want to know the time I will type date myself. I'm still thinking about leaving out the current hostname and current username... but for some reason I've become attached to seeing elektron (my hostname) on the screen.

But a prompt can always be done better. So first a screenshot with some comments about my new prompt (btw: what a lousy jpg, but I'm in no mood to make a better one)

A few things have changed in this prompt:

• shorter username, show only the first character. Why do you need more?
• use $SSH_TTY to tell if this is remote login or not, if so print a @
• use signal names when the exit code indicates that the prev. command received one. So no more 130, but -INT.

short username and ssh

I will only document the actual changes in this prompt, for the shorter username I use: ${USER[1]}, which yields the first character.

For ssh I use:

if [ -z $SSH_TTY ]; then
    ZSSH=
else
    ZSSH='@ '
fi

Now the left side of the prompt becomes:

ZU=${USER[1]}
PS1=$'$C_BLUE%(1j.$myjobs% $C_OFF .$C_OFF)%B$ZSSH%b%m.%B$ZU%b$C_OFF$C_L_GREEN%#$C_OFF '

signal names

My right side prompt shows the exit code of the previous command, but of course only when it is not 0. I've extended this to show the signals names in case the exit code is larger than 127.

setup the signal names and put them in an array:

ZSIG=$(kill -l)

And in precmd() we index in the $ZSIG array to pinpoint the correct signal name using the exit code. This is the prepended with a - to mimic the kill command syntax.

# add the name of the signal if its there
# must be done here in this function... 
EX=`print -P %?`
# EX=$(print -P %?) # does not work...
if [[ $EX -ge 128 ]]; then
    ((k=$EX-128))       # calculate the index in ZSIG
    E="-${${(s: :)ZSIG}[$k]}"  # split ZSIG on space and index with $k
else
    E=$EX
fi

The complete right side of the prompt then becomes:

RPSR=$'$C_OFF$C_RED%(0?.$C_OFF. $E)$C_OFF'

The full file can be downloaded here

I've created a new latex style to mimic some old school UNIX manuals I've been reading the past few months. It's a very plain style that keeps out of your face. This in contrast with the blockbook style

This is how it looks:

You can read about it a small howto doc. To use it, you will also need the class file.

UPDATE I've updated the style file so that the description lists will be indented with the same amount of space, no so more

item1  explanation
longer item  explanation

but like this

item1        explanation
longer item  explanation
even longer item
             explanation

This was done with the help of the LaTeX Companion. This is more in the style of manpages (according to the Companion). See line 100 in atstyle.cls.

Hmmm, this is the second time in 1 year that I had a corrupt filesystem on my raid partition. I saw no other option than mke2fs -j /dev/md7.

My first problem with XFS started on my fileserver, which only had 256 MB of memory. Turns out XFS was OOM-ing inside the kernel, this in turned messed up the filesystem. xfs_repair was also running out of memory. When I finally got enough virtual memory in this box xfs_repair was kind enough to segfault. Ok, shit happens, mkfs.xfs and try again.

I've moved the raid services off this under powered box and put the disks in my normal server with 2 GB of memory. But today I wanted to remove some old backups which heavily uses hardlinks. my guess is that there are a few million on that (backup/raid) partition alone. This failed, it started to spew out errors after having ran for an hour.

OK.

I killed the rm, umounted the filesystem, mounted in again so that XFS could recheck it. This worked; i.e. the filesystem was still OK. Next I thought it would be a good idea to run xfs_repair again on it to double check.

Then I went to work.

After coming home again, it still wasn't finished. OK. I got my USB hard disk out, cp-ed the stuff over and:

mke2fs -j /dev/md7

The GNOME decadence thread got me thinking. What does GNOME give me? (I consider myself a hardcore UNIX user). Well... it gives a nice interface with a nice terminal implementation (gnome-terminal). Further more with the recent Ubuntu 8.04, it also provides

• PulseAudio, never got that working btw, went back to ALSA.
• Tracker, what the hell was ever wrong with locate? Never got that working, and when I did, it was dog slow.
• I should be using evolution for emailing... no thanks! I'm a happy mutt user.
• There is no support for VI-key bindings in GTK... (which is not gnome's fault, but irritating none the less)

So I purged GNOME from my system and started using Xmonad, a tiling window manager. I'm still using GTK applications, because most of them still rule. But I'm happy that I'm leaving this whole GNOME business behind.

I'm publishing this for my own future reference. A short usage guide on git for an ex-svn addict.

goal	client	server
init .git repo	git init	git init
start remote repo	git clone ssh://server
add a file	git add $file	git add $file
commit the file	git commit -a -m"log"	git commit -a -m"log"
upload to server	git push origin master
import remote changes		git reset --hard
get changes from server	git pull

Yes! rdup has found its way into Debian: rdup_0.6.0-1.html

It is always fun to be able to apt-get install your own programs.

Note: this is an older article that I've revived. Also note: in todays email flood I don't know if such a popup is something you want to use...

intro

I've used gnubiff, xbiff and God knows what to provide a simple notify when receiving mail. But I wanted more. I want to be able to tweak certain settings, without going in to the source code of the application. Also the way mail notifiers mess with your mailbox is not something I particularly like.

what then?

I wanted something that runs from .procmailrc, so that every time an email comes in an action is undertaken. This means no fiddling with your mailbox, because it just runs from the .procmailrc.

using procmail to notify you

First I just played a sound from .procmail, but I also wanted some popup which could display the From: and/or the Subject field(s).

GNOME notify popup

I wanted to use the notify-send to give me the mailpopups as these are much more slicker than a gmessage. The .procmail part is the same as described below, only the script is different. The program notify-send is part of the package libnotify-bin

I now call a script called mailpop.sh which looks like this:

#!/bin/bash
# popup a small notification with 'notify-send'
dis=`formail -X From: -X Subject:`
# sometimes the order is difference - in very short headers
# check for both
if [[ "$dis" =~ "From:(.+)Subject:(.+)" ]]; then
    from=${BASH_REMATCH[1]}
    sub=${BASH_REMATCH[2]}
fi
if [[ "$dis" =~ "Subject:(.+)From:(.+)" ]]; then
    from=${BASH_REMATCH[2]}
    sub=${BASH_REMATCH[1]}
fi

# tweaks < > are special
from=${from//</\(}
from=${from//>/\)}
from=${from//&/\.}
sub=${sub//</\(}
sub=${sub//>/\)}
sub=${sub//&/\.}

sub=${sub:0:75}
from=${from:0:75}
TM=2000

# from http://gnome-hacks.jodrell.net/hacks.html?id=82
# modified for GNOME-2.14
pids=`pgrep -u miekg gnome-panel`
for pid in $pids; do
    # find DBUS session bus for this session
    DBUS_SESSION_BUS_ADDRESS=`grep -z DBUS_SESSION_BUS_ADDRESS \
        /proc/$pid/environ | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
    # use it
    DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS \
    /usr/bin/notify-send -u normal -t $TM "$sub" "$from"
done

The tricky part was getting the SESSION_BUS_ADDRRESS thingy.

hooking up .procmailrc

That is a bit of a no brainer, just add something like the following:

# notify the user
:0 c
* 
| $HOME/bin/mailpop.sh

In your .procmailrc. That's it. When ever a mail comes in a popup is displayed and a sound is heard, and you can tweak this is much as you like.

On Jun the 7th I gave a little presentation about DNSSEC at the NLLGG meeting. The presentation is in Dutch and the title is: "DNSSEC, wat is het? Komt het er ooit nog van?"

(DNSSEC, what is it? Does it ever happen?)

the pdf of the presentation

I've been using git for some time now, but as mentioned elsewhere the learning curse for this 'stupid content tracker' is quite steep.

Right now I finally seem be getting the hang of it and can use it in a svn like manner.

So we have:

• adding a file to a reposity: git add <file>
• committing it to the local branch: git commit -a -m"log"
• uploading it to the remote master: git push origin master

And the one that took about 2 months to find:

• updating the master branch with the changes pushed from remote branches: git reset --hard