tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Support for boolean queries in apropos



On Mon, 12 Mar 2012 06:45:15 +0200
Alan Barrett <apb%cequrux.com@localhost> wrote:

> Please don't make users learn new syntax.  I expect many users 
> will already familiar with the syntax offered by google search, so 
> I think it's a good idea to re-use that syntax.

On Tue, 13 Mar 2012 22:13:10 +0000
David Laight <david%l8s.co.uk@localhost> wrote:
> > No, using "-" to present binary not is a bad choice. apropos uses
> > getopt and requiring the use of "--" to terminate the option list
> > is a bad idea.
> 
> You also don't want to use & and | as these will also need quoting.

As Mouse said, the limited argot of a search engine is a subset of
Boolean algebra.  With parenthesis, De Morgan tells us AND and
NOT yields OR.  How is preventing or forcing a (synthesized) OR
is a step forward.  

We do have some prior art.  The Bourne shell and test(1) use !, -a, and
-o. find(1) and nmh use !, -and, and -or.  SQL and tcpdump use 'not',
'and', and 'or'.  Would it be so very bad to use one of those?  Surely
anyone typing "apropos" in a shell has used, or at least will soon use,
one of those utilities.   

I suggest tcpdump's choice, for three reasons:

1.  It's easier to type and read.
2.  It converts directly to the SQL. 
3.  Quoting is minimized. 

For convenience, I would add two features:

1.  add ANY and ALL
2.  because parentheses are interpreted by the shell, 
    permit [] in place of ()

Now imagine Abhinav's query. All the following are equivalent:

        $ apropos any [add new user] and not [git or ssh]
        $ apropos any [add new user] and not any [git ssh]
        $ apropos any [add new user] and not git and not ssh
        $ apropos [add or new or user] and not [git or ssh]

or perhaps the intended query was:

        $ apropos all [add new user] and not [git or ssh]
        $ apropos add and new and user and not [git or ssh]

Parentheses can be used instead of square brackets if the user prefers
more natural syntax to extra quoting.  Keywords in quotes are just
text.  Single or double quotes would trap whitespace, as in the shell.

(I assume "foo bar" becomes "foo[[:space:]]+bar".  An argument can
be made for full RE support, as a transparent pass-through, but I'm
not going to make it.)  

I can't wait.  Is it done yet?  ;-)

--jkl


Home | Main Index | Thread Index | Old Index