Scylla and Charybdis, FAQ

#0 # '<?xml version=\"1.0\" encoding=\"ISO-8859-2\"?>'
parse error line=1 column=30: unknown encoding

sed '1s/ISO-8859-2/ISO-8859-1/' xmlfile.xml | ./xml2sql-v.exe " 'test' " >xmlfile.sql

Expat then does not complain for wrong characters and still shall output ISO-8859-2 code (as it does not convert the characters).
OK, yes, it's quite ugly, but - hopefully - it shall work this way (no guarantees!) ;)

So if the compile succeeds just ignore such errors, please.

First (you only need to do this once per login) download my key from a keyserver, for example (note that the key ID can change in future):

gpg --keyserver pgp.mit.edu. --recv-keys 2C6BE86C

Now you can check the signature using the .asc file. For example, if you have downloaded

diskus-0.5.0-20081214-023903.tar.gz and diskus-0.5.0-20081214-023903.tar.gz.asc

then you can check it with

gpg diskus-0.5.0-20081214-023903.tar.gz.asc

If you dislike the cryptic output of GnuPG, then try

gpg --batch diskus-0.5.0-20081214-023903.tar.gz.asc 2>/dev/null </dev/null; echo $?

• If this gives you "0" (for OK), then everything is OK.
• If you see "1" you probably have a corrupt downlod (or mixed file names).
• If you see "2", then you need to download the key from the keyserver. The ID of the missing key is printed to STDERR by gpg, use the former variant to see it.

If you are puzzled how to enter this commands under Windows, consider installing CygWin. If you can understand German, perhaps you want to read my rants about GnuPG.

The only thing it tells you is:

• The download worked.
• Somebody, probably me, once has uploaded a proper key to the keyserver. Note that keyservers do not even check the eMail address.
• Somebody, probably me, was able to create a proper signature file and uploaded it to this server here.
• If somebody else, who is not me, is able to access my system unauthorized, it is very likely that this one can also fool you by creating a false signature and change all references to the signature to his one.
• Also it is a weak key (read: poorly defended), so it is possible that some evil person can gain access to my signing key somehow (in Germany, where I live, the state nowadays is allowed to compromize any computer's security using the Bundestrojaner, I am not able to protect my keys against that threat, therefor my key must be considered compromized, too)
• To get some more safety from all that key checking is an extremely complicated task, which even is error prone to absolute experts. So it is beyond any FAQ.
• So if you ask yourself, what this key checking everywhere is all about, then I only can say, it is plain snake oil
• Even I (only the rightfully owner of the signature) have limited checks to proof the validity of the signature. This check cannot be automated (any automation can be broken) and I can only check what I know of, so I cannot even find out if my keyfile was stolen somehow (as it is used for automatic signing, I cannot hide it away).
• You (the downloader) can tell from the signature IDs, that the files are somewhat related and that a newer version, which is signed by the same key, probably is not compromized, if the previous version you have, isn't compromized, too.

Please note, that I will support anybody, who tries to change my utilities such, that they can be added to some standard-package. Also note, that there is the RSS feed to stay informed about any changes to this site.

But I (probably) never will submit any of my tools to some standard- or semi-standard-package. This is for several reasons:

• I simply lack the time to do quality assurance. Sometimes changes break CygWin compatibility or backward compatibility (to S.u.S.E. 5.3 for example). I will fix this as soon as I notice (or need this feature on some other platform), but often this will take months to years.
• The tools seem to share a common code base (my library), but this library changes frequently and often breaks things. So the tools are not on the same level of the common code base. If the tools are combined somewhere, it would be right to base them on the same common code level. That's too much effort for me now.
• Everything is continuously evolving. I add things as soon as I need something or when I am on it, find the time and think, it would be nice to have. This is bad for some "standard" distribution, as it is irritating if tools are not "stable".
• I want to be able to change every aspect of my tools. As soon as they become somewhat "standard" this will make this widely impossible. It's hard to drop a feature against a big userbase. Today you can simply require a certain version of my tool (all old versions can be downloaded here as well).
• Many of my tools have a really weird or very unusual way to do things. But they are lacking a common default way to do it. For example "printargs", "md5chk" and "sq3" each have different defaults when it comes to how to escape things to the shell. This is confusing, so it probably would be wise to fix that first. If I had the time to do it, I would have done this already.
• Doing it in several small tools perhaps is stupid. I want to combine things into a better suited toolset somehow, but I am not really sure where this will lead me to. Note that I am working (very slowly) on something called "shit", which means "SHell-IT" or "SHell Intetgrated Tools", which will - as the name says - provide some tool-into-tool-integration, which probably make several of my tools superfluous, as some functions can be reached in a more common (perhaps a little bit more elaborate) way.
• I often replace standard tools (like tee) with my own version (like unbuffered), just because the standard tool does not do what I expect. For 99% of all tasks the standard tool is enough, but for the 1% lacking I need to re-invent the wheel. (For example I really have trouble with that /bin/sh does not support coprocesses well. Ksh and bash5 are of no relief, as either it is not available or not widely deployed.) This is not the right way to do it. The right way to do it to get the standard utilitiy to support my needs. But I will never succeed with such a task, so the tools are written for solely my own purpose for now and perhaps can help out others.
• Some tools are badly implemented versions of more useful utilities, for example "socat" is extremely powerful when it comes to networking needs. However often I need just a small subset of this possibilities, and the capacity of the machine might be limited (like an NSLU2 or some 16 MB machine which is over 10 years old), such that I need such a stripped down tool. Adding it to some package would be redundant.
• Also I am not happy with quite some of them, but I am lacking the time to make them fit together in a better way. I cannot submit anything I am not completely happy with. For example: gcopy was done in a hurry, and therefor was based on mvatom, which means, it is unsuitable for what I want it to do on the long term, so there is a long way to go until I would suggest it to others.