Re: [dict-beta] match-command

[Rik F. <fa...@di...>]

On Wed  9 Feb 2000 17:21:10 +0100,
   Christian Gebauer <ge...@bi...> wrote:
> 1) The "match *" feature behaves not like I would expect from the
> rfc.
> 
> Example:
> christian@rotes56:~ > telnet dict.org 2628
> [..]
> match * exact test
> 152 2 matches found
> web1913 "Test"
> wn "test"    
> [..]
> match foldoc exact test
> 152 1 matches found
> foldoc "test"
> [..]
> match jargon exact test
> 152 1 matches found
> jargon "test"   
> 
> "define *" and a "match" for each specific database return the
> correct result, but I don´t want to force the user to load
> the list of available databases to do basic querys.
> Is this simply a bug in dictd? Both dictd 1.4.9 and 1.5.0 show
> this behaviour.

This looks like a bug in the server.  Thank you for reporting it.

In daemon.c, the daemon_count_matches and daemon_dump_matches routines
appear to assume that all words are in the same database.  I'll try to fix
this soon.

> 2) "match" and webster
> The webster database contains many entrys with subentrys, so 
> I get the same entry over an over again when I simply fetch all the
> definitions a "match" yields. (I want to display the results directly,
> like dict(1) does) Is there a intellegent way to filter the redundant
> definitions out?

This may require a protocol extension to handle -- i.e., a mark that says
this entry is the first.  Or, as you suggest below, a DEFINE command that
can take a strategy.

> ad hoc heuristic: store the first line of the last definition
> and compare it to the first line of the new one. Can I take
> for granted that the hits for one definition will apear in
> one contiguous block?

I'm not sure what you're asking, but this heuristic won't work for "food",
because Vacuole is between two Food entries.

> Something like "define" with other strategies would be nice,
> since the server has the context information to eliminate these 
> surplus hits easily.