NetBSD Problem Report #50437

From www@NetBSD.org  Mon Nov 16 17:37:28 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E6925A64EF
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 16 Nov 2015 17:37:28 +0000 (UTC)
Message-Id: <20151116173727.CA818A6558@mollari.NetBSD.org>
Date: Mon, 16 Nov 2015 17:37:27 +0000 (UTC)
From: jmcneill@invisible.ca
Reply-To: jmcneill@invisible.ca
To: gnats-bugs@NetBSD.org
Subject: man -k lwp_park no longer finds _lwp_park man page
X-Send-Pr-Version: www-1.0

>Number:         50437
>Category:       bin
>Synopsis:       man -k lwp_park no longer finds _lwp_park man page
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 16 17:40:00 +0000 2015
>Last-Modified:  Mon May 30 03:30:00 +0000 2016
>Originator:     Jared McNeill
>Release:        7.0
>Organization:
>Environment:
NetBSD dis 7.0 NetBSD 7.0 (BEAGLEBONE.201509250726Z) evbarm
>Description:
The new "man -k" doesn't find _lwp_park man page when searching for lwp_park:

  dis$ man -k lwp_park
  apropos: No relevant results obtained.
  Please make sure that you spelled all the terms correctly or try using better keywords.

Old implementation does:

  dis$ APROPOS=-l man -k lwp_park
  _lwp_park(2) - wait interruptably in the kernel

>How-To-Repeat:

>Fix:

>Audit-Trail:
From: Abhinav Upadhyay <er.abhinav.upadhyay@gmail.com>
To: NetBSD GNATS <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: bin/50437
Date: Mon, 30 May 2016 00:26:01 +0530

 Hi,

 I think this is a special case. The new apropos tries to search for
 exact keywords as mentioned in the query and then tries to rank the
 documents which contain those keywords. While the old apropos used to
 do a grep kind of match in the NAME section and it could find partial
 matches (like lwp_park and _lwp_parK).

 I think the new apropos could handle such kind of issues. I have a
 proposed solution:

 Try to do a full text search for the query, if no results obtained,
 fallback to legacy mode search. However, there are few side-effects:

 1. If any of the man pages contain the keyword, then the legacy mode
 search wouldn't be triggered. For example, if a man page had the
 keyword lwp_park, then it would match and then apropos wouldn't fall
 back to the legacy search.

 2. The output of the legacy mode search wouldn't contain the snippets,
 because it doesn't use the full text search. So at times it might seem
 weird that the output contains snippet and other times it doesn't :)

 I will post a patch soon.

 -
 Abhinav

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/50437
Date: Mon, 30 May 2016 03:29:46 +0000

 On Sun, May 29, 2016 at 07:00:02PM +0000, Abhinav Upadhyay wrote:
  >  Hi,
  >  
  >  I think this is a special case. The new apropos tries to search for
  >  exact keywords as mentioned in the query and then tries to rank the
  >  documents which contain those keywords. While the old apropos used to
  >  do a grep kind of match in the NAME section and it could find partial
  >  matches (like lwp_park and _lwp_parK).
  >  
  >  I think the new apropos could handle such kind of issues. I have a
  >  proposed solution:
  >  
  >  Try to do a full text search for the query, if no results obtained,
  >  fallback to legacy mode search. However, there are few side-effects:

 I think it might be a better approach to try to teach the text
 retrieval engine that 'foo' and '_foo' (maybe also '__foo__') are
 similar words.

 Patching this special case by doing arbitrary substring searches will
 generate all kinds of false positives.

 -- 
 David A. Holland
 dholland@netbsd.org

Home	PR Database Search