Why does htsearch show the “&” character as “&” in search results?
In version 3.1.5, htsearch was fixed to properly re-encode the characters &, <, >, and ” into SGML entities. However, the default value for the translate_amp, translate_lt_gt and translate_quot attributes is still false, so these entities don’t get converted by htdig. If you set these three attributes to true in your htdig.conf and reindex, the problem will go away.In the 3.2 betas there was a bug in the HTML parser that caused it to fail when attempting to translate the “&” entity. This has been fixed in 3.2.0b3. The translate_* attributes are gone as of 3.2.0b2.5.23. I get Internal Server or Unrecognized character errors when running htsearch.An increasingly common problem is Apache configurations which expect all CGI scripts to be Perl, rather than binary executables or other scripts, so they use “perl-handler” rather than “cgi-handler”. The fix is to create a separate directory for non-Perl CGI scripts, and define it as such in your httpd.conf file.
In version 3.1.5, htsearch was fixed to properly re-encode the characters &, <, >, and ” into SGML entities. However, the default value for the translate_amp, translate_lt_gt and translate_quot attributes is still false, so these entities don’t get converted by htdig. If you set these three attributes to true in your htdig.conf and reindex, the problem will go away. In the 3.2 betas there was a bug in the HTML parser that caused it to fail when attempting to translate the “&” entity. This will be fixed in 3.2.0b3. The translate_* attributes are gone as of 3.2.0b2. 5.23. I get Internal Server or Unrecognized character errors when running htsearch. An increasingly common problem is Apache configurations which expect all CGI scripts to be Perl, rather than binary executables or other scripts, so they use “perl-handler” rather than “cgi-handler”. The fix is to create a separate directory for non-Perl CGI scripts, and define it as such in your httpd.conf file. You should define it the s
