where target.rc is the full filename to the configuration file for this instance of the program. It contents is described in detail in the next section.
Now, anubis switches to the daemon mode. Theoretically, we could have used DejaGNU's remote.exp to talk to the daemon. However, DejaGNU is not able to handle TLS encryption, so this method does not suite our needs.
As usual, both target and interface configuration files are created from their corresponding *.in source files. The purpose of this step is to expand variables TESTDIR and TOP_SRCDIR, thereby providing correct paths to data and binary files. Usually this is done on compilation time by testsuite/etc/Makefile.am. However, to launch the first (authmode) instance of anubis we need to know the port number to bind to. Using any predefined port number is not a good idea, as it may be in use at the time the testsuite is run. Prompting the user to supply the port number is even worst.
It is supposed that save_to_file writes to the file whose name is given in its first argument the lines from the list given as its second argument.
The amount of time elapsed between creation of the target configuration file and launching first anubis instance should be as small as possible, in order to diminish the probability of some other process occupying the port number retuned by findport. So, it is preferable to start first anubis instance right after creating configuration file for it.
Theoretically, it is still possible that by the time first anubis starts up the port number will become occupied. This will cause the testsuite to fail, so we should make sure an appropriate diagnostic message will be issued.
However, the probability of such failure is quite small. I have been using this approach in GNU Radius testsuite for more than four years and I cannot remember ever having encountered such a situation.
Writing LINGUA engine was a great experience and it has shown that eXtrans is a nice idea. It has, however, some deficiences. Some of them were already fixed (I hope to make CVS repository available soon). The two most important ones remain:
The diagnostics does not help to find out the exact place in the XML file where the error occurred. Its an awful work to scan the entire source to find out a misplaced or mistyped tag. I have made some improvements which do help in certain cases, but the main part of work is still ahead.
Keeping a separate database of target-source file dependencies makes it difficult to use eXtrans in makefiles. Both Ellinika and Runasimi use all-local rule to override the difficulty, but the solution is far from being optimal.
I'd like to rewrite eXtrans so that it produces usual makefiles instead of keeping its own database of files to be modified.
An interesting approach would be to create a derivative class from XTransBase which would override set_output so that it would add appropriate output file name to the makefile rule being generated. The rest of methods should probably simply call pass and do nothing. At the end of processing this auxiliary class would output the rules it has generated (and, possibly, purge orphan html files).
mailutils Coredumped on reading a single escape character. Wonder why no one has noticed this before!
tar GNU multivolume cannot accept members with filenames longer than 100 characters to straddle the volume boundary. It did not check filename length, however.
Committed a fix to the problem recently spotted by Wojtek: when switching to the user's privileges anubis did not clear the list of complementary groups.
Luca Fibbi reported that version 1.14 incorrectly skipped members in a PAX archive. It turned out that it was incorrectly deeming the members to be sparse, and that, in turn, due to the fact that the member header was not decoded prior to calling skip_member(). Lots of interdependencies...
The "error_t on Sparc" problem has been solved! It turned out that one of Guile includes defined error_t without defining symbol __error_t_defined. It's easy to fix, but Guile people should have known better than doing such things.
I have a strong feeling that back in the days when we were editing our code with ed (I still use it quite often, I must admit) our code contained less errors and was far more readable than today.
I have just finished cleaning up my buddy's code that was written on a 120-columns-per-line screen and contained quite a few copy-n-paste bugs. Sure, one can read a 120-chars single-line declaration. One can even read a whole 80-line screen of such declarations, but I strongly doubt whether one will really understand what he has read and be able to spot out the error. Especially when one has been looking at his screen for 20 straight hours, you know.
My todo list is quite long (as usual), but I have a strong urge to play charango... Its strings will surely keep me away from the console today. Chores will wait. Vielleicht das nächste Mal:))
Implemented XELO extension. XDATABASE EXAMINE now works using MD5 hashes, just as was proposed in the initial 'pixie-dixie' draft.
Lots of changes. Still cannot understand why compiling guimb/main.c fails at argp.h on Sparc. Hopefully Alex will be able to provide a preprocessor output file, this should solve the puzzle...
Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.