According to Rick Richardson:
> Gilles Detillieux writes...
> > > However, when htsearch creates the results page, the HTML it
> > > generates omits the -c option:
> > >
> > > <FORM method="get" action="/cgi-bin/htsearch">
> > >
> > > Using only the configuration file, how can I convince htsearch to
> > > add the -c option to the HTML it generates?
> >
> > Using the -c option to htsearch is not the preferred approach to specifying
> > the configuration file. That option is mainly for testing and debugging
> > purposes. Usually, you specify the configuration file using the "config"
> > input parameter to htsearch. It's defined as a hidden input parameter
> > in the sample search.html form that comes with the package. The limitation
> > with this is the file you specify must be under the CONFIG_DIR directory
> > defined at compile time. The default value for "config" is "htdig", which
> > expands to "$CONFIG_DIR/htdig.conf". As long as $SCONF is subordinate to
> > the compiled-in CONFIG_DIR value, this shouldn't be a problem.
>
> Foo. This isn't going to fly. I want to cut this whole thing as a CD
> ROM to be mounted under /home/httpd/html/<dir> on any convenient
> machine (that has htsearch installed in cgi-bin). Thus the need for
> no references to specific machine names in the database, and thus the
> need for everything to be self contained in its own directory tree.
> And I expect to have several different <dir>'s independantly indexed
> this way and possibly mounted at the same time.
>
> The RFC's are just one example, but I also want to do this
> with several huge mail archives.
OK, but if you're using the system's own cgi-bin/htsearch to generate the
search results, and the results will have relative references to the
matched documents (e.g. <a href="http:rfc/rfc822.txt">...</a>), then
the browser is going to interpret these relative references as being
under the cgi-bin directory, won't it? I don't see a way to get around
requiring absolute references, which means setting up a custom htsearch
config file on the target system. If you're going to do that, why not
just make sure the file (or files) gets put into the right config directory?
You should also be aware that the htdig/htsearch databases are architecture
dependent - a little-endian database won't work on a big-endian machine,
or vice-versa. There's also the version dependency aspect of htdig to
consider. 3.1.1 through 3.1.3 are DB version compatible, but in general,
different htdig versions have historically meant different DB formats.
3.2 will bring about some major changes.
> Sounds like I'm going to need to hack htsearch to be a little more
> flexible in where it can take its config file from, and carry around a
> custom binary of that program.
>
> OK, I should have downloaded the source in the first place.
Then your CD will be even more architecture (and OS) specific. This will
also require having the HTTP server configuration on the target system
set up to allow running CGI programs from wherever the CD will be mounted.
I hope I'm not raining on your parade. I think you have a great idea
here, but I'm just trying to think of issues you'll need to deal with.
Good luck.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
