Re: [htdig-dev] Possble Bugs, esp with htdig.conf

[Gilles D. <gr...@sc...>]

According to BOOTH, Nicholas, FM:
> I've noticed the following which may, or may not be "real" bugs when testing
> the new Beta version:

It's usually best to deal with these one at a time, as you're unlikely to
find one person who can answer all questions at once.  You can always try
again if any of your questions slip through the cracks.

> 1] The htdig.conf file seems to be very, very sensitive to whitespace at the
> end of lines. In particular, with a multiline attribute as illustrated just
> below, if there is white space (tested with [tab]s)  after the \  character,
> htdig _and_ htsearch will fail:
>  
> server_aliases:                 www.cbfm.rbs.co.uk=www.cbfm.rbsgrp.net
> <http://www.cbfm.rbs.co.uk=www.cbfm.rbsgrp.net>  \
> 
>                                 www.cib.rbs.co.uk=www.cib.rbsgrp.net
> <http://www.cib.rbs.co.uk=www.cib.rbsgrp.net> 

This isn't really a bug, but rather it's pretty much standard behaviour
among most Unix-like utilities I've seen that use backslash for multi-line
configuration definitions.  It's actually pretty logical when you stop and
think about it.  The backslash escapes the character IMMEDIATELY following
it, somehow altering it's meaning (usually to include it literally).
So, <backslash><newline> would mean take the newline in as part of the
definition instead of it's usual meaning of the end of the definition.
If you go and stick a space or tab after the backslash, then you're
escaping that space or backslash, not the newline.

> 3] If there is _not_ a return after the last line in the config file then
> htsearch causes a cgi error.  Results from apache eror log:
>  
> Unknown char in line 224: #[Fri Nov 14 23:51:46 2003] [error] [client
> 147.114.74.200] malformed header from script. Bad header=syntax error:
> /var/www/cgi-bin/htsearch32 

That's because you're using the wrong editor.  If you use vi, it will
ensure that the last line ends with a newline.  ;-)  Seriously, in 3.2 we
moved from a simple format parsed directly in some C++ code, to a more
elaborate format allowing blocks of config attributes.  That required
us going with a more complex parser written in flex and bison.  I don't
know how much control we have over how these will deal with an improperly
terminated final line -- it may be out of our hands.  I'll see if I can
figure something out.

-- 
Gilles R. Detillieux              E-mail: <gr...@sc...>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)