Andreas Bernauer's personal blog

I've recently stumbled across the following error message of Gnuplot:

illegal month

Gnuplot can handle time data. With set timefmt, you can specify the format of your time data. As of know, all your time data has to be in the same format, that is, all columns containing time data must have the same format.

Although every column used the same format, I still got this error message. Strangely enough, if I tested the plot command within gnuplot, the error message disappeared; only when I ran the script to plot the data the error message appeared.

Turns out that the reason for the error message is not a malformed data line, but a malformed command. In my case, I have used the wrong format for specifying the coordinates of set arrow, because I wrote the script with time data that had a different format. Changing the coordinates to adhere to the new time format made the error message disappear.

After upgrading to Ubuntu 10.04, vimperator could not read or write its .vimperatorrc anymore. Although all permissions were set correctly, the access to this file was denied. The access is also denied to firefox if you want to save a file as '.vimperatorrc'. Strangely, this is true for any file named '.XYZrc' in your home directory. The error message in the logs is

May 29 12:34:27 quick kernel: [ 7021.689247] type=1503 audit(1306665267.160:49):
operation="mknod" pid=4195 parent=1 profile="/usr/lib/firefox-3.6.17/firefox-*bin"
requested_mask="c::" denied_mask="c::" fsuid=1000 ouid=1000 name="/home/andreas/.vimperatorrc"

The access is denied by apparmor, in particular because of a rule in the privacy settings that disallows read or write access to *.rc files in the user's home directory. I don't know, why this broad apparmor rule is necessary, but I found a workaround for the .vimperatorrc problem. Reading the vimperator sources, I found that the configuration file is expected as '.vimperatorrc' (which causes the aforementioned problem) or '_vimperatorrc' (for Windows machines). It turns out that if on both GNU/Linux and Windows platforms one of the files does not exist, the other one is tried instead.

So, to let vimperator read its .vimperatorrc file, just rename .vimperatorrc to _vimpeatorrc. And keep in mind that firefox cannot read or write any file named *rc in your home directory (such as .my-vimperator.rc).

Alternatively you can disable apparmor (which I don't recommend) or update the apparmor rules (which I don't know how to do without removing the offending rule in the privacy profile as the manual page is incomplete here as far as I can see).

I've recently upgraded my system from Ubuntu 8.02 to 10.04 (Lucid Lynx). After the reboot, my wireless PCI card with Intersil Prism 2.5 Wavelan chipset (rev 01) did not work anymore.

First I thought the driver for this rather old card is missing. However, it turned out the interface was named wrong by the udev rules.

To fix the issue, I edited /etc/udev/rules.d/70-persistent-net.rules. There were two entries for my wireless card, one for the hostap_pci driver that named the interface wlan0 and one for the orinoco_pci driver that named the interface eth1. As eth1 showed up with ifconfig, but wlan0 did not, I figured orinoco_pci is working, but hostap_pci is not. So I changed the following lines in 70-persistent-net.rules from

# PCI device 0x1260:0x3873 (hostap_pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:09:5b:11:e2:c9", 
    ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# PCI device 0x1260:0x3873 (orinoco_pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:09:5b:11:e2:c9", 
    ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

to

# PCI device 0x1260:0x3873 (hostap_pci)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:09:5b:11:e2:c9", 
    ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x1260:0x3873 (orinoco_pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:09:5b:11:e2:c9", 
    ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

That is, I commented out the section for hostap_pci and renamed the entry for orinoco_pci to use wlan0 as the interface name.

After a reboot, I could use my wireless network again.

Update: However, a new entry was added to the udev rules file so that after the next reboot, my wireless network card did not work anymore. The culprit was the udev rules generator file at /lib/udev/rules.d/75-persistent-net-generator.rules, which thought it still had to add a udev rule for the eth1 interface. I don't know how to debug udev rules, so the easiest way to fix this issue is to disable the rule generation once everything is set up nicely. For this, I added the following line at the beginning of the 75-persistent-net-generator.rules file, with the effect that no further rule generation for network cards happens:

GOTO="persistent_net_generator_end"

Of course, if you add or change your network cards, you should uncomment this new line to generate new rules.

I'm currently evaluating Zimbra as my webmail client. It looks pretty nice and even has keyboard shortcuts.

However, the listings available on the net seem to be outdated or not match with my configuration, so I copied the listing from the Preferences dialog and put them on a cheat sheet, that you can download here: Zimbra Keyboard Shortcuts (PDF).

Who's designing the error messages of g++? Anyways, here is a translation:

error: request for member ‘foo’ in ‘((Test*)this)->Test::_bar’, 
which is of non-class type ‘C_bar*’

means: in class Test, you've written _bar.foo, but _bar is a pointer; you need to write _bar->foo, that is, change the dot to an arrow.

Happy C++ coding!

I just stumbled over my python code, similar to the following one, which raises an UnboundLocalError in the first line of push:

def func_stack1():
    stack = []
    def push(num):
        print "stack before: ", stack
        stack = stack + [num]
        print "stack after: ", stack
    return push

push = func_stack1()
push(1)

I wanted to 'upgrade' my python from 2.5 to 2.6 on Ubuntu. Unfortunately, I could not find .deb packages for Ubuntu. Fortunately, the Python 2.6 sources (sig) are available, so I can compile it from source. Here's what I had to do to get it running. (Short version: apt-get build-dep python2.5 and apply this patch to disable unavailable and outdated modules.)

I gvim, if you set

:setlocal spell spelllang=en_us

gvim will spell-check your file and underline wrongly spelled words with a red line much like you know it from OpenOffice. If you

:set mousemodel=popup

you can even right click on any misspelled word to get a list of suggested corrections.

However, this sometimes did not work for me. I could not figure out a reason, until I read the help docs again, which clearly say:

Note for GTK: don't release the right mouse button until the menu appears, 
otherwise it won't work.

They actually mean what they say: if I release the right mouse button too fast, the menu appears, but it does not replace the misspelled word with the corrected word. Only if keep the right mouse pressed until the menu appears, it works, for whatever reason. RTFM!

If you link a static library to your executable, the GNU linker ld (as many others) only adds those symbols that ld thinks are actually used in your executable (that's a feature). Unfortunately, ld can only check if the symbol is in use, but not if the side effects of the symbol's initialization is used. Thus, your program will fail if it depends on the initialization of an unused static object.

In my case, I have a factory (class module::factory<T> : public factory_plant {...} factory;) at which classes can register themselves with a name (module::factory<Group> f("Group")). If I call the factory with a name (factory.create("Group")), the factory returns a pointer to a newly created class associated with that name. The class registers itself via a static object (here: f) whose initialization code does the actual registration.

The problem arises if the class is not used directly and the linker throws the static object away. The registration does not happen and thus I can't use the factory to create an object of the class. There are several possibilities to work around this feature:

Use --whole-archive to tell the linker to include all symbols, no matter what (with gcc use -Wl,--whole-archive -lmylib -Wl,--no-whole-archive). The drawback is that symbols that I neither use nor care about are also included, resulting in increased code size.

Use -u<symbol> to tell the linker to treat <symbol> as if undefined and thus include it in the executable, even it is not used. The drawback here is to know what <symbol> looks like. Easy for C files, difficult (and not portable) for C++ files (see Name mangling in Wikipedia).

Use static initializers (thanks to Alex for this). This is my preferred method. I use a throw-away class, which I add to the header file:

static struct Init {
     Init() {
          static module::factory<Group> init("Group");
     }
} init;

I always have to look it up how to restrict access to some files or directories on my web server, so I write it down here. Two steps:

1. You need a password file
2. You must specify the restrictions

When you connect to a host that you have not connected to before via ssh, ssh prints a message like

lava:~$ ssh lava
The authenticity of host 'lava (134.2.14.48)' can't be established.
RSA key fingerprint is 9e:1a:5e:27:16:4d:2a:13:90:2c:64:41:bd:25:fd:35.
Are you sure you want to continue connecting (yes/no)?

Usually, you say yes and enter your password. With this, you accept the encryption key the server sent you as the actual encryption key of the server (as opposed to an encryption key some eavesdropper might have sent you who sits between you and the server you connect to). You are supposed to accept the encryption key only if you compared the received encryption key with the actual encryption key of the server by comparing their fingerprints. However, how do you get the fingerprint of the actual encryption key?

I found the Howto on the gcc inline assembler difficult to understand, so I wrote up the major parts here and created some kind of summary.

On my machine running Fedora 7, I saw message like

/etc/selinux/targeted/contexts/files/file_contexts: 
  Multiple same specifications for /usr/local/lost\+found/.*.

for some files or directories, especially when doing an yum update or running rpm. I checked the file_contexts file, but I could not find any duplicates.

The solutions was some stale file_contexts.pre file in the same directory, which was a copy of file_contexts with some modifications. After deleting the file_contexts.pre file, the messages disappeared.

I'm still wondering, where this file_contexts.pre file came from, as it did not belong to any package.

Writing meaningful error message is sometimes hard. Even harder is understanding error message of someone else's program. Today I was buffeled with an error message from cfengine:

cfengine:lava: image exists but destination type 
               is silly (file/dir/link doesn't match)
cfengine:lava: source=/afs/wsi/wsi/environment/fedora/6/cfengine/
               config/ti-background.png,dest=/usr/share/pixmaps

How can a destination type be silly? And what file/dir/link does not match?

Looking into the sources (see second match) revealed that the destination type refers to the type of dest, that is /usr/share/pixmaps, which is a directory. This type does not match the type of the source /afs/wsi/.../ti-background.png, which is a regular file.

So the solution to the problem is explicitly naming the target file in the cfengine configuration files:

dest=/usr/share/pixmaps/ti-background.png

I wish the error message from cfengine would be a bit more verbose on this. But now I know what the error message means, and so do you.

Today a small hint that can save you a lot of debugging time when writing shell scripts. If you start your (bash) shell script with
set -u -e
unset parameters won't expand to nothing (-u) and the script ends immediately when one command fails (-e) unless it is part of a test (if, while, ||, etc., see bash(1)).

If you want to debug your shell script, you either insert echo commands throught your script, or you can just insert
set -v -x
at the top. This will turn on verbose mode (-v) in which bash will print the input lines as they are read. The execution trace (-x) mode will print the commands after expansion but before execution, so you can check if the command is invoked the way you intended.

I thought about posting similar hints for tcsh, but who is shell scripting in tcsh anyways?