Andreas Bernauer's personal blog

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?

I tried to package some documentation files generated with doxygen using checkinstall and rpm today. Unfortunately, rpm seems to be unable to handle file names in the %files section that contain some "special characters" suchs '?', '*', '[', and ']'. In my particular case I had a file called 'html/structboost_1_1call__traits_3_01T[N]_4.html' (from the SystemC library), which I could not get listed in the %files section.

There has been a post on the rpm-devel list over a year ago, but the long time maintainer of RPM, Jeff Johnson, seems to not care about file names containing "special characters" for whatever reason. The original poster said he wants to submit a patch that fixes the bug. I don't know if that happened, I only know that rpm 4.4.2 (still?) can't handle special characters in the %files section.

As for workarounds:

• Escaping with backslash does not work ("File not found: html/structboost_1_1call__traits_3_01T\[N\]_4.html")
• Replacing with question marks does not work, either ("File glob not found: html/structboost_1_1call__traits_3_01T[N]_4.html").
• Mention a directory containing the file with the special file name does work ("html/").

Situation: checkinstall is a tool that builds you an RPM (or Debian or Slackware) package while installing some software with make install or similar. RedHat integrated SELinux to increase the safety of Linux in their Fedora distribution.

Problem: checkinstall and SELinux don't play well together. The installation process with checkinstall fails, although a regular make install succeeds.

Solution: The cause for the problem is the file system translation mechanism that checkinstalll uses. You can tell checkinstall to not use the file system translation mechanism by either providing the command-line option --fstrans=no or editing the config file (usually in /usr/local/lib/checkinstall/checkinstallrc) to say TRANSLATE=0 (and INSTALL=1 to actually install something).

The file system translation option can be used to merely create the package without actually installing it, so that no files can be overwritten. However, when used together with SELinux, the security context of the created file system tree is incorrect and thus the installation fails. If you want to install the package, you don't need the file system translation and the BACKUP option should put you on a safe side (as long you don't use suid programs for installation).

Situation: RedHat based distributions like Fedora allow you to create kickstart files to automatically install machines without human intervention. The kickstart file contains a set of commands that are understood and executed by the anaconda installer. The kickstart file also allows comments that start with '#'

Problem: Using quotes within the comment will confuse the installer.

Solution: The only solution I know of is not using quotes within comments such as "# this won't hurt"