On 3/22/2000 at 12:00 PM, [EMAIL PROTECTED] (Geoff Hutchison)
wrote:
> I would guess it's finding the htdig.conf from 3.1.2, which probably
> sets the default DB location?
Thank you for the tip about -c to htsearch; it was indeed looking at an
elderly and obsolete config file. I pointed it at the same file
specified by the HTML form, and the DB2 errors went away.
Results from htsearch at the command line, with the config specified
with -c, now work fine as far as I can tell -- they begin with
"Content-type: text/html\n\n", read correctly from the database, and
pull the right templates. The results from the web, though, are
unchanged -- no data.
I verified that the "conf" directory is set correctly by temporarily
renaming it, and sure enough, both the web results and the command-line
results each complained that htsearch couldn't find the specified config
file. The same thing happened when (with the conf directory properly
returned to normal) I temporarily renamed the config file itself.
The only other variable is format, which is set to 'standard' in both
the HTML form and at the command line.
> Are you sure this is the most recent htsearch binary?
My results page includes the $VERSION variable, and the successful
command line results say 3.1.5.
Addressing the bigger picture -- I can't find a rationale for htsearch
printing its DB2 complaints in advance of the content-type declaration.
It was a minor detriment to troubleshooting before, when I had to go to
the command line to see htsearch's output, and (if more DB2 errors are
responsible for the current round of web silence) it's a major detriment
now that I can't seem to replicate the glitch from the command line.
htsearch tries to print a helpful error message in these cases, but
it'll never get to the browser.
Thanks very much for your time.
-nat
------------------------------------
To unsubscribe from the htdig mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
