apropos(1) option naming

apropos(1) option naming

[Ingo Schwarze]

Hi,

i have done some research regarding apropos(1) option naming,
but i'm out of time for drawing conclusions right now.

Yours,
  Ingo

Except that maybe, i still hope for something like

  apropos -s 3 -Q Xr open and Er ENOENT
  apropos -s 4 -Q An Gray or An Reyk

 ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 -----

Options, arguments, and environment of the following utilities:
man(1) apropos(1) whatis(1) whereis(1) which(1)

OVERVIEW
========

general agreement:

 -a  all
 -B  binary search path
 -b  search for binaries  
 -C  config file
 -c  copy to stdout
 -d  debug
 -k  keyword search like apropos(1)
 -M  override MANPATH
 -n  use nroff (historic)
 -P  pager
 -T  output device (historic)
 -t  use troff (historic)

agreement for individual programs:

 -f  find like whatis(1) (man)
 -f  end of search path (whereis)
 -m  search for manual pages (whereis)
 -S  subsection (man apropos)
 -S  search path for sources (whereis)
 -s  section (man apropos)
 -s  search for sources (whereis)
 -u  update cache (man) (Linux only)
 -u  search for unusual (whereis)
 -w  where (man)

important clashes:

 -h  SYNOPSIS only (4.3BSD-Net/2 NetBSD OpenBSD)
 -h  help (FreeBSD Linux)
 -m  prepend to MANPATH (man apropos whatis 4.3BSD-Reno NetBSD OpenBSD)
 -m  override MACHINE_ARCH (man FreeBSD)
 -m  another operating system (man apropos whatis Linux)

unimportant clashes:

 -e -l -p -r

used by a single system:

 -D -E -H -I -i -K -L -o -q -R -V -v -W -X -x -Z

completely free:

 -A -F -G -g -J -j -N -O -Q -U -Y -y -z


DETAILED LISTING:
=================

-7 [Linux man] display as pure US-ASCII

-a [OpenBSD man whereis which] display all matching pages
app: 4.3BSD-Tahoe man
app: OpenBSD 2.3 whereis which
[NetBSD man which]
[FreeBSD man whereis which]
[Linux man which]
-a [Linux apropos] logical "and" of keywords

-B path [FreeBSD whereis] path to search for binaries
app: 2BSD whereis
[Linux whereis]

-b [FreeBSD whereis] search for binaries
app: 2BSD whereis
[Linux whereis]

-C file [OpenBSD man apropos whatis] alternate configuration file [man.conf(5)]
app: NetBSD 1.0 man apropos whatis
[NetBSD man apropos whatis]
[Linux man catman apropos whatis]

-c [OpenBSD man] copy to standard output
app: 4.3BSD-Reno man
[NetBSD man]
[Linux man] internal option to be used by catman(1) only

-D [Linux man] reset options to the defaults

-d [FreeBSD man apropos whatis] print debugging information
[Linux man catman whatis]

-E encoding [Linux man] generate specific output character encoding

-e [Version 7 AT&T UNIX man] proprocess by eqn(7)
-e [Linux man] select subsystem (e.g. tcl manuals)
-e [Linux apropos] use exact matches only

-f command [OpenBSD man] synonym for whatis(1)
app: 4BSD man
[FreeBSD man]
[Linux man]
-f [FreeBSD whereis] delimit list of directories after -BMS
app: 2BSD whereis
[Linux whereis]

-H browser [Linux man] produce HTML output

-h [OpenBSD man] display only the SYNOPSIS
app: 4.3BSD-Net/2 man
[NetBSD man]
[FreeBSD man] display short help message
[Linux man catman apropos whatis] like FreeBSD

-I [Linux man] match case when searching for manual pages

-i [Linux man] ignore case when searching for manuals (the default)

-K [Linux man] full text grep over all manuals

-k keyword [POSIX OpenBSD man] synonym for apropos(1)
app: 4BSD man
[NetBSD man]
[FreeBSD man]
[Linux man]

-L [Linux man apropos whatis] force a specific locale

-l [Linux man] local files only, no MANPATH
-l [Linux apropos whatis] do not trim output to terminal width

-M path [OpenBSD man apropos whatis] override MANPATH
app: 4.3BSD man
app: 4.3BSD-Tahoe whatis
app: 4.3BSD-Reno apropos
[NetBSD man apropos whatis]
[Linux man catman apropos whatis]
[FreeBSD man whereis]
app: 2BSD whereis
[Linux whereis]

-m path [OpenBSD man apropos whatis] prepend to MANPATH
app: 4.3BSD-Reno man apropos whatis
[NetBSD man apropos whatis]
[FreeBSD man] override MACHINE_ARCH and MACHINE
-m [FreeBSD whereis] search for manual pages
app: 2BSD whereis
[Linux whereis]
-m system [Linux man apropos whatis] display pages of another operating system

-n [Version 7 AT&T UNIX man] invoke nroff for display on standard output

-o [FreeBSD man] forced use of non-localized pages

-p [NetBSD man] print MANPATH
-p [NetBSD whereis] use PATH
-p [FreeBSD man] use roff preprocessor, override MANROFFSEQ
-p string [Linux man] use specified roff preprocessor

-P [FreeBSD man] override PAGER [more -s]
[Linux man]

-q [FreeBSD whereis] quiet

-R [Linux man] recode

-r [Linux man] change less(1) prompt
-r [Linux apropos whatis] use regular expression matching

-S subsection [OpenBSD man apropos] restrict to architecture
app: OpenBSD 2.3 man
app: OpenBSD 4.5 apropos
[NetBSD man apropos]
[FreeBSD man] restrict to section list, override MANSECT
[Linux man] like FreeBSD
-S path [FreeBSD whereis] path to search for sources
app: 2BSD whereis
[Linux whereis]

-s section [OpenBSD man apropos] restrict to section
app: OpenBSD 2.3 man
app: OpenBSD 4.5 apropos
[NetBSD man apropos]
[Linux apropos whatis]
-s [FreeBSD whereis] search for source files
app: 2BSD whereis
[Linux whereis]
-s [FreeBSD which] silent

-T device [Linux man]
app: somewhere before 4.4 BSD (not sure, would need to check)

-t [FreeBSD man] invoke troff for phototypesetting
app: Version 7 AT&T UNIX man
[Linux man]

-u [FreeBSD whereis] search for unusual entries
app: 2BSD whereis
-u [Linux man] update cache (requires SUID)

-V [Linux man catman apropos whatis] display version information

-v [Linux apropos whatis] verbose warnings

-W [Linux man] list the pathnames of matching formatted pages

-w [OpenBSD man] list the pathnames of the matching pages
app: Version 7 AT&T UNIX man
[NetBSD man]
[FreeBSD man]
[Linux man]
-w [Linux apropos whatis] use shell wildcard matching

-X [Linux man] display using gxditview(1)

-x [FreeBSD whereis] do not use expensive search tools

-Z [Linux man] use a roff postprocessor

keywords ... [OpenBSD apropos] ignoring case, considering parts of words
app: 2BSD apropos
[NetBSD apropos]
[FreeBSD apropos]
[Linux apropos]

name ... [OpenBSD man whatis whereis which] display pages entitled name ...
app: Version 3 AT&T UNIX man: restricted to one name
app: Version 4 AT&T UNIX man: allowing more than one name
app: 2BSD whatis whereis
app: 3BSD which
[NetBSD man whatis whereis which]
[FreeBSD man whatis whereis which]
[Linux man whatis whereis which]

MACHINE [OpenBSD man] restrict to architecture
[NetBSD man]
[FreeBSD man]

MANPAGER [OpenBSD man] alternative manual pagination program [more(1)]

MANPATH [OpenBSD man apropos whatis] manual search path
[NetBSD man apropos whatis]
[FreeBSD man apropos whatis]

PAGER [OpenBSD man] alternative pagination program [more(1)]
[NetBSD man]

PATH [OpenBSD which] command search path
[FreeBSD apropos whatis]

whatis.db [OpenBSD apropos whatis] apropos database file
[NetBSD apropos whatis]

/etc/man.conf [OpenBSD man apropos whatis] default man(1) configuration file
[NetBSD man apropos whatis]
[FreeBSD man]
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

apropos "types" (WAS apropos(1) option naming)

[Kristaps Dzonsons]

Hi Ingo,

I'm tagging out a release right now; in the coming one, we can focus 
much more on getting the options Just Right.

> Except that maybe, i still hope for something like
>
>    apropos -s 3 -Q Xr open and Er ENOENT
>    apropos -s 4 -Q An Gray or An Reyk

I'd like to spend some time on this.  I'll speak aloud because I'm still 
undecided.  Let's consider just the matchings in your statements above 
(e.g., An Gray) and assume logical operators exist.  (The rest is for a 
different thread.)

The current state of option matching is by symbolic type: "func foo" to 
query all functions named "foo".  Functions, in this case, are defined 
by `Fo' and `Fn'.  These definitions are encoded when the database is 
created; the source macro type is lost.

I could change the database to instead encode only the mdoc macro name, 
as in your example.  Then "Fo foo AND Fn foo" would match the above. 
The problem with this so far is that it's not user friendly at all.  It 
assumes users know about mdoc, and in general they don't.  Furthermore, 
it doesn't work for -man, because now we need to do things like `SH foo 
AND Sh foo' for sections.  This gets ugly.  And then what happens for 
the -man description, or name?  It has no macro at all.  Making people 
search for `Nd text' and having it also search -man, which has no `Nd', 
is confusing because sometimes there'd be a macro, sometimes not.

But that's ok, actually.  Because we could let apropos have some 
symbolic types, like "function", that would magically expand into "Fo 
foo AND Fn foo", hiding the types from the users.  Something like 
"section" would expand into "Sh foo AND SH foo".  And "desc" into `Nd' 
for -mdoc and the free-form description for -man.

But then... for something like the description, we would have a symbolic 
name but not a macro name.  This is confusing.

Overall I'm still on the fence as to the best approach.  On the one hand 
we have lots of flexibility, but significant complexity.  On the other 
hand, we have a tighter database, but our choices for types may appear 
arbitrary.

I slightly prefer, however, the best approach of biting the pillow and 
trying to determine the best symbolic types, which will be encoded 
directly in the database as they are now.  If we do a good job, we can 
probably match the flexibility of `Xr open' without the complexity (not 
even to mention that many macros aren't semantically interesting).  But 
I'm open to suggestions, so please chime in!

Take care,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: apropos "types" (WAS apropos(1) option naming)

[Ingo Schwarze]

Hi Kristaps,

Kristaps Dzonsons wrote on Sat, Oct 08, 2011 at 05:13:32PM +0200:

> I'm tagging out a release right now; in the coming one, we can focus
> much more on getting the options Just Right.

Sure, and i'll merge the release soon.

>> Except that maybe, i still hope for something like
>>
>>   apropos -s 3 -Q Xr open and Er ENOENT
>>   apropos -s 4 -Q An Gray or An Reyk

> I'd like to spend some time on this.  I'll speak aloud because I'm
> still undecided.

So am i, so let's throw ideas at each other.

> Let's consider just the matchings in your
> statements above (e.g., An Gray) and assume logical operators exist.
> (The rest is for a different thread.)
> 
> The current state of option matching is by symbolic type:

Yes, and i do want matching by symbolic type.

> "func foo" to query all functions named "foo".

However, i don't we to invent new names for symbolic types, but instead
use the existing ones, those defined by mdoc(7) macro names.

> Functions, in this case, are
> defined by `Fo' and `Fn'.  These definitions are encoded when the
> database is created; the source macro type is lost.

Sure, i see no need to save the exact source macro type.

> I could change the database to instead encode only the mdoc macro
> name, as in your example.  Then "Fo foo AND Fn foo" would match the
> above. The problem with this so far is that it's not user friendly
> at all.  It assumes users know about mdoc, and in general they
> don't.

Well, they don't know about "func" either, and learning "func" is
rather useless, learning "Fo" is more useful and hardly more difficult.

By the way, i would map .Fn this way:
 - first argument, all but the last word -> .Ft
 - first argument, last word -> .Fo
 - remaining arguments -> .Fa

So in the database, you don't see which macro was actually used,
but you get maximal semantic information.

In the user interface for searching, .Fn will be an alias
for .Ft | .Fo | .Fa.

If you do insist on "func", we can provide that as an alias
for .Fn, but i looks a bit like bloat of limited usefulness.

> Furthermore, it doesn't work for -man, because now we need
> to do things like `SH foo AND Sh foo' for sections.  This gets ugly.

Well, let's just map .SH to .Sh; done.
We don't want to make anybody learn man(7) macros.
It's a legacy language that only a handful of specilists need to
understand nowadays.

> And then what happens for the -man description, or name?  It has no
> macro at all.

That's a delicate task for later.
The only way i see is heuristic guessing.
When the code clearly follows usual conventions and the engine
is confident what's going on, it will map, even without macros.
When the code looks strange and the guessing engine is unsure, don't
map at all - bogus db entries are very annoying, so be conservative.

> Making people search for `Nd text' and having it also
> search -man, which has no `Nd', is confusing because sometimes
> there'd be a macro, sometimes not.

No, i don't think it's confusing.  Users should not worry what
the actual code of a specific page is.  They don't search for
pages containing the .Nd macro.  But they will learn that the
Name section Description (if the parser can find it) is .Nd,
and they will search for the Name section Description, not
worrying whether the actual source code is mdoc(7) or man(7).

> But that's ok, actually.  Because we could let apropos have some
> symbolic types, like "function", that would magically expand into
> "Fo foo AND Fn foo", hiding the types from the users.  Something
> like "section" would expand into "Sh foo AND SH foo".  And "desc"
> into `Nd' for -mdoc and the free-form description for -man.

No, my goal is not to have the user interface require knowledge
of such technicalities.  I do want symbolic types.  I just want
their names derived from mdoc(7) - because that actually makes
the interface *simpler*.  People who know what they are doing
don't need to learn anything new at all.

> But then... for something like the description, we would have a
> symbolic name but not a macro name.  This is confusing.
>
> Overall I'm still on the fence as to the best approach.  On the one
> hand we have lots of flexibility, but significant complexity.  On
> the other hand, we have a tighter database, but our choices for
> types may appear arbitrary.
>
> I slightly prefer, however, the best approach of biting the pillow
> and trying to determine the best symbolic types, which will be
> encoded directly in the database as they are now.  If we do a good
> job, we can probably match the flexibility of `Xr open' without the
> complexity (not even to mention that many macros aren't semantically
> interesting).  But I'm open to suggestions, so please chime in!

I think i wouldn't put .Em into the database at all, because
who is going to search for underlined text?  That's of very
limited usefulness at best.

Let's look at the mdoc(7) macro overview.
I think the following are useful as search keys:

 - Document preamble and NAME section macros
   (perhaps excluding Os, at least at first)
 - Sections and cross references
   (excluding .Sx, .Pp, and .Lp)
 - .Bd, .D1, .Dl are special cases.
   Maybe they warrant *one* common search key, or none,
   or one for -literal, one for -filled.
   Not sure yet.
 - .Bl is a special case.
   .Bl -tag .It is probably interesting - or maybe not.
   .Bl -bullet is probably pointless and will just be skipped.
   Not sure yet.
 - .%* is very interesting.
 - Semantic markup for command line utilities
 - Semantic markup for function libraries
 - Various semantic markup
 - Text production (maybe)

The following are irrelevant:
 - Spacing control
 - Physical markup
 - Physical enclosures (or maybe? Brq, Aq? Not sure yet.)

Oh, by the way.
Maybe we don't need an option at all:

  apropos An=Gray An=Reyk
  apropos Xr=open \& Er=ENOENT
  apropos 'Xr=open & Er=ENOENT'

Traditionally, multiple arguments mean "or", so the authors
are or'ed.  So we need a good syntax for "and".  The Linux
syntax "-a" is not powerful enough (it just switches the whole
command line to "and" logic) and clashes badly with man -a,
whatis -a, whereis -a.  The above is not yet very nice.
Well, the "or" case is, but the "and" case - hmm...

Anyway, my point is that almost no useful .Nm/.Nd contains
the character '=', so we can just prefix the search type to
the search key, right?

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: apropos "types" (WAS apropos(1) option naming)

[Kristaps Dzonsons]

Hi Ingo,

I thought I'd sent this mail.  Well, here it goes again...

On 08/10/2011 23:01, Ingo Schwarze wrote:
> Hi Kristaps,
>
> Kristaps Dzonsons wrote on Sat, Oct 08, 2011 at 05:13:32PM +0200:
>
>> I'm tagging out a release right now; in the coming one, we can focus
>> much more on getting the options Just Right.
>
> Sure, and i'll merge the release soon.
>
>>> Except that maybe, i still hope for something like
>>>
>>>    apropos -s 3 -Q Xr open and Er ENOENT
>>>    apropos -s 4 -Q An Gray or An Reyk
>
>> I'd like to spend some time on this.  I'll speak aloud because I'm
>> still undecided.
>
> So am i, so let's throw ideas at each other.
>
>> Let's consider just the matchings in your
>> statements above (e.g., An Gray) and assume logical operators exist.
>> (The rest is for a different thread.)
>>
>> The current state of option matching is by symbolic type:
>
> Yes, and i do want matching by symbolic type.
>
>> "func foo" to query all functions named "foo".
>
> However, i don't we to invent new names for symbolic types, but instead
> use the existing ones, those defined by mdoc(7) macro names.
>
>> Functions, in this case, are
>> defined by `Fo' and `Fn'.  These definitions are encoded when the
>> database is created; the source macro type is lost.
>
> Sure, i see no need to save the exact source macro type.
>
>> I could change the database to instead encode only the mdoc macro
>> name, as in your example.  Then "Fo foo AND Fn foo" would match the
>> above. The problem with this so far is that it's not user friendly
>> at all.  It assumes users know about mdoc, and in general they
>> don't.
>
> Well, they don't know about "func" either, and learning "func" is
> rather useless, learning "Fo" is more useful and hardly more difficult.

Yes!  This is exactly the bit of logic I needed to push me into being 
comfortable with this idea.

The way I see it now is that, well, the user will have to consult the 
manpage to learn the various types anyway.  Whether it's "func" or "Fo" 
is the same to them.  This is enough for me!  Then all your arguments 
below follow... `Fo' notation is more economical and bolsters knowledge 
of mdoc(7), etc.  I'm sold.

> By the way, i would map .Fn this way:
>   - first argument, all but the last word ->  .Ft
>   - first argument, last word ->  .Fo
>   - remaining arguments ->  .Fa
>
> So in the database, you don't see which macro was actually used,
> but you get maximal semantic information.
>
> In the user interface for searching, .Fn will be an alias
> for .Ft | .Fo | .Fa.
>
> If you do insist on "func", we can provide that as an alias
> for .Fn, but i looks a bit like bloat of limited usefulness.
>
>> Furthermore, it doesn't work for -man, because now we need
>> to do things like `SH foo AND Sh foo' for sections.  This gets ugly.
>
> Well, let's just map .SH to .Sh; done.
> We don't want to make anybody learn man(7) macros.
> It's a legacy language that only a handful of specilists need to
> understand nowadays.
>
>> And then what happens for the -man description, or name?  It has no
>> macro at all.
>
> That's a delicate task for later.
> The only way i see is heuristic guessing.
> When the code clearly follows usual conventions and the engine
> is confident what's going on, it will map, even without macros.
> When the code looks strange and the guessing engine is unsure, don't
> map at all - bogus db entries are very annoying, so be conservative.

Yes, and you know I already match for most -man name/description cases, 
although I haven't empirically tested the extent of "most", here.

>> Making people search for `Nd text' and having it also
>> search -man, which has no `Nd', is confusing because sometimes
>> there'd be a macro, sometimes not.
>
> No, i don't think it's confusing.  Users should not worry what
> the actual code of a specific page is.  They don't search for
> pages containing the .Nd macro.  But they will learn that the
> Name section Description (if the parser can find it) is .Nd,
> and they will search for the Name section Description, not
> worrying whether the actual source code is mdoc(7) or man(7).
>
>> But that's ok, actually.  Because we could let apropos have some
>> symbolic types, like "function", that would magically expand into
>> "Fo foo AND Fn foo", hiding the types from the users.  Something
>> like "section" would expand into "Sh foo AND SH foo".  And "desc"
>> into `Nd' for -mdoc and the free-form description for -man.
>
> No, my goal is not to have the user interface require knowledge
> of such technicalities.  I do want symbolic types.  I just want
> their names derived from mdoc(7) - because that actually makes
> the interface *simpler*.  People who know what they are doing
> don't need to learn anything new at all.
>
>> But then... for something like the description, we would have a
>> symbolic name but not a macro name.  This is confusing.
>>
>> Overall I'm still on the fence as to the best approach.  On the one
>> hand we have lots of flexibility, but significant complexity.  On
>> the other hand, we have a tighter database, but our choices for
>> types may appear arbitrary.
>>
>> I slightly prefer, however, the best approach of biting the pillow
>> and trying to determine the best symbolic types, which will be
>> encoded directly in the database as they are now.  If we do a good
>> job, we can probably match the flexibility of `Xr open' without the
>> complexity (not even to mention that many macros aren't semantically
>> interesting).  But I'm open to suggestions, so please chime in!
>
> I think i wouldn't put .Em into the database at all, because
> who is going to search for underlined text?  That's of very
> limited usefulness at best.
>
> Let's look at the mdoc(7) macro overview.
> I think the following are useful as search keys:
>
>   - Document preamble and NAME section macros
>     (perhaps excluding Os, at least at first)
>   - Sections and cross references
>     (excluding .Sx, .Pp, and .Lp)
>   - .Bd, .D1, .Dl are special cases.
>     Maybe they warrant *one* common search key, or none,
>     or one for -literal, one for -filled.
>     Not sure yet.
>   - .Bl is a special case.
>     .Bl -tag .It is probably interesting - or maybe not.
>     .Bl -bullet is probably pointless and will just be skipped.
>     Not sure yet.
>   - .%* is very interesting.
>   - Semantic markup for command line utilities
>   - Semantic markup for function libraries
>   - Various semantic markup
>   - Text production (maybe)

Ok, I'm going to put together a potential list of types for review.  I 
anticipate the biggest "problem", user-interfacedly, will be that of 
discerning "Fo made in the SYNOPSIS" and "Fo referenced in the body".

> The following are irrelevant:
>   - Spacing control
>   - Physical markup
>   - Physical enclosures (or maybe? Brq, Aq? Not sure yet.)
>
> Oh, by the way.
> Maybe we don't need an option at all:
>
>    apropos An=Gray An=Reyk
>    apropos Xr=open \&  Er=ENOENT
>    apropos 'Xr=open&  Er=ENOENT'
>
> Traditionally, multiple arguments mean "or", so the authors
> are or'ed.  So we need a good syntax for "and".  The Linux
> syntax "-a" is not powerful enough (it just switches the whole
> command line to "and" logic) and clashes badly with man -a,
> whatis -a, whereis -a.  The above is not yet very nice.
> Well, the "or" case is, but the "and" case - hmm...

Why don't we just be a little more awesome and allow

  apropos '( An Gray && Xr open ) || ...'.

Meaning, the AND/OR/NOT logical operators and a notion of grouping?  It 
doesn't seem too hard: matching would still be pretty straightforward. 
In fact, once we start to do any Boolean logic, the distance between 
arbitrary expression (such as the above) and something like Linux's dumb 
"-a" is quite small.  Might as well go the distance.

Thoughts?

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

Re: apropos "types" (WAS apropos(1) option naming)

[Ingo Schwarze]

Hi Kristaps,

Kristaps Dzonsons wrote on Wed, Oct 12, 2011 at 11:08:37PM +0200:

> Ok, I'm going to put together a potential list of types for review.

The first time where it becomes relevant to fix the list is when we
enable apropos, because after that, people have to rebuild their mandoc
databases on production systems each time we change the database format.
Until then, adding to the list and reordering it is fine.
Of course, nothing is wrong with planning ahead, nothing at all.

> I anticipate the biggest "problem", user-interfacedly, will be that
> of discerning "Fo made in the SYNOPSIS" and "Fo referenced in the
> body".

Any pressing need?
To search for "Fo, but only in the SYNOPSIS", i'd search
for Nm in the first place.

Are there any other cases where limiting searches to certain
sections might be useful?  I'm not sure.

> On 08/10/2011 23:01, Ingo Schwarze wrote:

>>   apropos An=Gray An=Reyk
>>   apropos Xr=open \& Er=ENOENT
>>   apropos 'Xr=open & Er=ENOENT'

> Why don't we just be a little more awesome and allow
> 
>  apropos '( An Gray && Xr open ) || ...'.

Three comments:

 1. I'd hate the follwoing two to be semantically different:
      apropos An Gray
      apropos 'An Gray'
    As the meaning of the first is
      apropos Nm=An Nd=An Nm=Gray Nd=Gray
    i fear we probably need the '=' token.
    I'd gladly be convinced otherwise, though.

 2. Obviously, string operations are not bitwise operations, so i see
    no point in doubling the operators, & and | should be fine.
    There is no need for |, but we should probably allow it as
    an optional, ignored token, just for symmetry.

 3. I expect 90% of the searches will remain just
      apropos keyword 
    some will become
      apropos macro=keyword
    a few will involve one operator,
    and two operators and grouping will be very rare in practice.
    Still, as long as it doesn't complicate the syntax for
    simple searches, which it doesn't seem to, it's nice
    to support grouping as well.
    It is not urgent, though.

> Meaning, the AND/OR/NOT logical operators and a notion of grouping?
> It doesn't seem too hard: matching would still be pretty
> straightforward. In fact, once we start to do any Boolean logic, the
> distance between arbitrary expression (such as the above) and
> something like Linux's dumb "-a" is quite small.  Might as well go
> the distance.

Yaya, i agree with that.

At least we should start in such a way that the syntax we start
with allows going the full distance later.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv