bug#16722: 24.3.50; `M-x man' does not handle case appropriately

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Drew Adams]

Please reopen bug #10840, or fix it here.

This is Eli's comment on the Emacs bug that needs fixing:

  In any case, "M-x man" should handle this kind of output gracefully,
  which it evidently doesn't.

See bug #10840 for recipe and details.





In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-06 on ODIEONE
Bzr revision: 116299 rgm@gnu.org-20140207032552-3ycw6hai2zl7yynq
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Wolfgang Jenkner]

On Tue, Feb 11 2014, Drew Adams wrote:

> This is Eli's comment on the Emacs bug that needs fixing:
>
>   In any case, "M-x man" should handle this kind of output gracefully,
>   which it evidently doesn't.
>
> See bug #10840 for recipe and details.

Here's, AFAIK, the current state with regard to Drew's observations.

On Sat, Feb 18 2012, Drew Adams wrote:

> I have Cygwin installed (a rather old version; dunno which one or how to
> tell).
[...]
> M-x man RET
>  
> Hitting TAB (with no minibuffer input) completes the empty input to the
> two chars `^:'.

This is a consequence of (1) and (2) below; the OP could confirm (1),
while anybody can easily check (2) by looking at the code in man.el.

(1) `man -k' can't find any whatis database or all those files are
empty.

(2) This particular `man -k' sends "^: nothing appropriate" to stdout
and not to stderr (if the distinction is meaningful on cygwin), which is
supposed to mean that it's a line "from the summary database", see

http://pubs.opengroup.org/onlinepubs/009696799/utilities/man.html

> Thereafter I can do nothing with that.  Whether I type
> anything after the `^:' or not, TAB just completes to `^:'.

I think that has been fixed as a by-product of a 2013-01-10 change:

	(man): Flush the completion cache between uses.

I.e., the behaviour is now described by

> If I instead first type `l' (as in `ls') and then hit TAB, I get [No
> match].  It doesn't seem to matter what I type in the minibuffer: TAB
> always says [No match].

which seems to be irreproachable in the light of (1) above.

The behaviour is different in the latter case because `man -k ^l' sends
a message "^l: nothing appropriate" to stdout, so "^l" is collected as
a possible man page name, but since this string is not a completion of
the "l" prefix it is discarded, after all.

The description above holds true for Gnu or Gnu/* but it is a lie on
other systems, where the output of `man -k l' is collected instead, so
you would still presented with "l:" as a possible completion.

Now, this can happen on correctly installed systems as well (if you
happen to search for a prefix which doesn't match any substring in the
summary database), so by setting `Man-man-k-use-anchor' to nil on some
of those systems which are likely to use the man-1.* package without
correcting the bug described in (2) above I introduced a regression.

It seems (http://cygwin.com/packages/) that man-1.* is the man package
provided by default in cygwin, but I suppose cygwin packages could also
be used with a non-cygwin emacs?  Would it be reasonable to set the
default for `Man-man-k-use-anchor' to non-nil if the system type is
`cygwin' or `windows-nt' or `ms-dos'?

Wolfgang

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Drew Adams]

> > M-x man RET
> > Hitting TAB (with no minibuffer input) completes the empty input
> > to the two chars `^:'.
> 
> This is a consequence of (1) and (2) below; the OP could confirm
> (1),

Not sure how to check that.  In a bash shell (outside Emacs), if I
do `man -k' I get the question "What manual page do you want?".
If I then type `ls' then it is as if I typed `ls' from the outset:
the files in the current dir are listed.

If I do `man -k ls' or `man -k "ls"' or `man -k ^l' or `man -k "^l"
then I get only the message "ls: nothing appropriate" (or the same
with ^l instead of ls).

However, if (in bash, outside Emacs) I type `man ls' or `man "ls"'
then I get the normal `man' page output/behavior for `ls'.

> while anybody can easily check (2) by looking at the code in man.el.
> 
> (1) `man -k' can't find any whatis database or all those files are
> empty.
> 
> (2) This particular `man -k' sends "^: nothing appropriate" to
> stdout and not to stderr (if the distinction is meaningful on
> cygwin), which is supposed to mean that it's a line "from the
> summary database", see
> http://pubs.opengroup.org/onlinepubs/009696799/utilities/man.html
> 
> > Thereafter I can do nothing with that.  Whether I type
> > anything after the `^:' or not, TAB just completes to `^:'.
> 
> I think that has been fixed as a by-product of a 2013-01-10 change:
> 
> 	(man): Flush the completion cache between uses.

Not sure what you mean, but the behavior is not fixed for me.
I still get exactly the same behavior I reported, even with Emacs
builds from only a few days ago.

> I.e., the behaviour is now described by
> 
> > If I instead first type `l' (as in `ls') and then hit TAB, I get
> > [No match].  It doesn't seem to matter what I type in the minibuffer:
> > TAB always says [No match].
> 
> which seems to be irreproachable in the light of (1) above.

Dunno what that means, but that is still the behavior I see: there
is no completion for `M-x man'.

> The behaviour is different in the latter case because `man -k ^l'
> sends a message "^l: nothing appropriate" to stdout, so "^l" is
> collected as a possible man page name, but since this string is
> not a completion of the "l" prefix it is discarded, after all.
> 
> The description above holds true for Gnu or Gnu/* but it is a lie on
> other systems, where the output of `man -k l' is collected instead,
> so you would still presented with "l:" as a possible completion.
> 
> Now, this can happen on correctly installed systems as well (if you
> happen to search for a prefix which doesn't match any substring in
> the summary database), so by setting `Man-man-k-use-anchor' to nil
> on some of those systems which are likely to use the man-1.* package
> without correcting the bug described in (2) above I introduced a
> regression.
> 
> It seems (http://cygwin.com/packages/) that man-1.* is the man
> package provided by default in cygwin, but I suppose cygwin
> packages could also be used with a non-cygwin emacs?  Would it
> be reasonable to set the default for `Man-man-k-use-anchor' to
> non-nil if the system type is `cygwin' or `windows-nt' or
> `ms-dos'?

I am using MS Windows 7, and I have Cygwin installed.  FWIW, I
tried setting `Man-man-k-use-anchor' to `t', but that changed
nothing, AFAICT.  `M-x man' works normally, except that there is
no completion - completion is broken.

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Wolfgang Jenkner]

On Sat, Feb 15 2014, Drew Adams wrote:

>> > M-x man RET
>> > Hitting TAB (with no minibuffer input) completes the empty input
>> > to the two chars `^:'.
>> 
>> This is a consequence of (1) and (2) below; the OP could confirm
>> (1),
>
> If I do `man -k ls' or `man -k "ls"' or `man -k ^l' or `man -k "^l"
> then I get only the message "ls: nothing appropriate" (or the same
> with ^l instead of ls).
>
> However, if (in bash, outside Emacs) I type `man ls' or `man "ls"'
> then I get the normal `man' page output/behavior for `ls'.

Your man pages live in subdirectories of a small number of "root"
directories.  Let's assume that you have only one of those root
directories, say /usr/share/man.  If you type `man ls' the output comes
from a file /usr/share/man/man1/ls.1 (or perhaps from a pre-formatted
file /usr/share/man/cat1/ls.1 or perhaps from one of those with a .gz
suffix or something like that).

However, the output for `man -k ls' comes from a different file (the
same one for all man pages under this root directory), namely
/usr/share/man/whatis (other man packages may use a file with
a different name).

Since `man -k ls' doesn't give a summary for the `ls' man page I think
that

>> (1) `man -k' can't find any whatis database or all those files are
>> empty.

At least it doesn't have an entry for ls.  You should be able to create
this file by running the `makewhatis' command.

>> (2) This particular `man -k' sends "^: nothing appropriate" to
>> stdout and not to stderr (if the distinction is meaningful on
>> cygwin), which is supposed to mean that it's a line "from the
>> summary database", see
>> http://pubs.opengroup.org/onlinepubs/009696799/utilities/man.html
>> 
>> > Thereafter I can do nothing with that.  Whether I type
>> > anything after the `^:' or not, TAB just completes to `^:'.
>> 
>> I think that has been fixed as a by-product of a 2013-01-10 change:
>> 
>> 	(man): Flush the completion cache between uses.
>
> Not sure what you mean, but the behavior is not fixed for me.
> I still get exactly the same behavior I reported, even with Emacs
> builds from only a few days ago.

IIUC, you had the following in mind:

M-x man RET TAB C-g M-x man RET l TAB

used to give `^:' (because the cache of man page name completions was
not flushed between invocations of man).

If you set Man-man-k-use-anchor to t it should give [No match] now.

>> I.e., the behaviour is now described by
>> 
>> > If I instead first type `l' (as in `ls') and then hit TAB, I get
>> > [No match].  It doesn't seem to matter what I type in the minibuffer:
>> > TAB always says [No match].
>> 
>> which seems to be irreproachable in the light of (1) above.
>
> Dunno what that means, but that is still the behavior I see: there
> is no completion for `M-x man'.

As explained above the source for the completions is the `whatis' file
at a man root directory.  As for `irreproachable', I found it funny to
describe the behaviour in "moral" terms, sorry if this was confusing.

Wolfgang

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Drew Adams]

> Since `man -k ls' doesn't give a summary for the `ls' man page I
> think that
> 
> >> (1) `man -k' can't find any whatis database or all those files
> >> are empty.
> 
> At least it doesn't have an entry for ls.  You should be able to
> create this file by running the `makewhatis' command.

Maybe so, and good to know; thanks.  But a priori I don't want to
have to do that.

IIRC, I used to, with an older version of Cygwin, have `M-x man'
provide completion without having to do anything at all.

> >> > Thereafter I can do nothing with that.  Whether I type
> >> > anything after the `^:' or not, TAB just completes to `^:'.
> >>
> >> I think that has been fixed as a by-product of a 2013-01-10
> >> change:	(man): Flush the completion cache between uses.
> >
> > Not sure what you mean, but the behavior is not fixed for me.
> > I still get exactly the same behavior I reported, even with
> > Emacs builds from only a few days ago.
> 
> IIUC, you had the following in mind:
> 
> M-x man RET TAB C-g M-x man RET l TAB

Not necessarily.  Why `C-g'?  If the first TAB shows all
completions then I might just type `l TAB' to narrow that down.

But this is a detail.  Sure, what you wrote is something I would
also expect to work.  You didn't say what you expect to happen
after the first TAB, but if it is to show all possible
completions then yes.

> used to give `^:' (because the cache of man page name completions
> was not flushed between invocations of man).
> 
> If you set Man-man-k-use-anchor to t it should give [No match] now.

No, it does not.  I did this:

M-x man C-g  ; Load library man, since `Man-man-k-use-anchor'
             ; is not yet defined (this step not really needed)

M-: (setq Man-man-k-use-anchor t)

M-x man RET TAB  ; Shows ^: as the sole completion.

It does not say [No match].  Did I understand you correctly that
you thought it would, or am I missing something?

AFAICT, the value of `Man-man-k-use-anchor' makes no difference.
If setting that to non-nil solved the problem then things would
be fine.  I have no problem setting another variable in my setup.

(FWIW: Why isn't this variable a user option?)

> > that is still the behavior I see: there is no completion for
> > `M-x man'.
> 
> As explained above the source for the completions is the `whatis'
> file at a man root directory.

Isn't it possible to have `M-x man' provide completion without
users having to use `makewhatis'?  I think that was the case
in the past.  Or if it is necessary (for Cygwin), then why not
have Emacs do that when necessary (upon user confirmation)?

Why should an Emacs user have to know about this at all, and
invoke such a shell command directly?

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Eli Zaretskii]

> From: Wolfgang Jenkner <wjenkner@inode.at>
> Date: Sat, 15 Feb 2014 18:17:08 +0100
> Cc: 16722@debbugs.gnu.org
> 
> It seems (http://cygwin.com/packages/) that man-1.* is the man package
> provided by default in cygwin, but I suppose cygwin packages could also
> be used with a non-cygwin emacs?  Would it be reasonable to set the
> default for `Man-man-k-use-anchor' to non-nil if the system type is
> `cygwin' or `windows-nt' or `ms-dos'?

It is much better, IMO, to probe for "man -k" support the first time
"M-x man" is invoked, like we do with "M-x grep".  Relying on
system-type should only be a very distant second candidate (e.g., what
if Windows machines will get a proper 'man' command that does supports
apropos databases?).

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Wolfgang Jenkner]

On Sat, Feb 15 2014, Eli Zaretskii wrote:

>> It seems (http://cygwin.com/packages/) that man-1.* is the man package
>> provided by default in cygwin, but I suppose cygwin packages could also
>> be used with a non-cygwin emacs?  Would it be reasonable to set the
>> default for `Man-man-k-use-anchor' to non-nil if the system type is
>> `cygwin' or `windows-nt' or `ms-dos'?
>
> It is much better, IMO, to probe for "man -k" support the first time
> "M-x man" is invoked, like we do with "M-x grep".  Relying on
> system-type should only be a very distant second candidate (e.g., what
> if Windows machines will get a proper 'man' command that does supports
> apropos databases?).

But `man -k' always works (to the extent we need it to) if the whatis
database is correctly installed.

In particular, for Drew's case, please see

http://permalink.gmane.org/gmane.emacs.bugs/68879

As the doc string of  `Man-man-k-use-anchor' states,

       Setting the value to nil always gives correct results but
       computing the list of completions may take a bit longer.

The problem is just a bug in this particular implementation, viz.,
`man -k' sends error messages to stdout.  Strictly speaking, POSIX
requires emacs to assume that everything in stdout represents content
from the whatis database, but this is not desirable in this case.
Setting `Man-man-k-use-anchor' to non-nil works around this annoyance,
for the reasons I explained in this bug thread.

Wolfgang

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Eli Zaretskii]

> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: 16722@debbugs.gnu.org
> Date: Sun, 16 Feb 2014 02:08:32 +0100
> 
> On Sat, Feb 15 2014, Eli Zaretskii wrote:
> 
> >> It seems (http://cygwin.com/packages/) that man-1.* is the man package
> >> provided by default in cygwin, but I suppose cygwin packages could also
> >> be used with a non-cygwin emacs?  Would it be reasonable to set the
> >> default for `Man-man-k-use-anchor' to non-nil if the system type is
> >> `cygwin' or `windows-nt' or `ms-dos'?
> >
> > It is much better, IMO, to probe for "man -k" support the first time
> > "M-x man" is invoked, like we do with "M-x grep".  Relying on
> > system-type should only be a very distant second candidate (e.g., what
> > if Windows machines will get a proper 'man' command that does supports
> > apropos databases?).
> 
> But `man -k' always works (to the extent we need it to) if the whatis
> database is correctly installed.

No, it doesn't.  For example, it isn't supported with this clone:

  http://sourceforge.net/projects/ezwinports/files/man-1.4-bin.zip/download

And, as demonstrated in this bug report, it can backfire when the
database is not "correctly installed".

My suggestion will gracefully handle both cases.

> The problem is just a bug in this particular implementation, viz.,
> `man -k' sends error messages to stdout.  Strictly speaking, POSIX
> requires emacs to assume that everything in stdout represents content
> from the whatis database, but this is not desirable in this case.
> Setting `Man-man-k-use-anchor' to non-nil works around this annoyance,
> for the reasons I explained in this bug thread.

If you are saying that users should set an option to avoid this
problem, I might agree (although I don't think this option will help
for the above clone).  However, having Emacs detect this automatically
is even better.

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Wolfgang Jenkner]

Since the both of you seem to agree that emacs should magically fix
important (but easily fixed) deficiencies in your system setup, do as
you please and I'll leave it at that.

Wolfgang

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Drew Adams]

> Since the both of you seem to agree that emacs should magically fix
> important (but easily fixed) deficiencies in your system setup, do as
> you please and I'll leave it at that.

Coming back to this bug (which is still there).

I did try running `makewhatis', BTW.  That just raised a bunch of errors:

makewhatis
FIND: Invalid switch
FIND: Invalid switch
FIND: Invalid switch
FIND: Invalid switch
FIND: Invalid switch
-uThe system cannot find the file specified.

I also tried it using `makewhatis -w', but that didn't help:

makewhatis -w
cp: cannot create regular file `/cygdrive/c/Program/whatis': No such file or directory
cp: cannot create regular file `Files/GnuWin32/man/whatis': No such file or directory
cp: cannot create regular file `/cygdrive/c/Program/whatis': No such file or directory
cp: cannot create regular file `Files/GnuWin32/man/whatis': No such file or directory
-uThe system cannot find the file specified.
FIND: Invalid switch
FIND: Invalid switch
FIND: Invalid switch
FIND: Invalid switch
FIND: Invalid switch
-uThe system cannot find the file specified.
-uThe system cannot find the file specified.
-uThe system cannot find the file specified.

That created an empty `whatis' file in directory
c:/cygwin/usr/share/man.  Having that file did not help, of course.

Hard to believe that something that used to work so simply with
Cygwin, without users needing to do anything, no longer works.

Is there really no possibility that Emacs will fix this?

I can of course use `woman' with completion, and I can still use
`man' without completion.  But it really seems like `man' should
be able to offer completion that works, out of the box.

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Eli Zaretskii]

> Date: Wed, 1 Feb 2017 11:25:43 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16722@debbugs.gnu.org
> 
> > Since the both of you seem to agree that emacs should magically fix
> > important (but easily fixed) deficiencies in your system setup, do as
> > you please and I'll leave it at that.
> 
> Coming back to this bug (which is still there).
> 
> I did try running `makewhatis', BTW.  That just raised a bunch of errors:
> 
> makewhatis
> FIND: Invalid switch
> FIND: Invalid switch
> FIND: Invalid switch
> FIND: Invalid switch
> FIND: Invalid switch
> -uThe system cannot find the file specified.

Your system is mis-configured: it finds the Windows find.exe before
(or instead) finding the Cygwin find.exe.  You should re-arrange your
PATH.

> makewhatis -w
> cp: cannot create regular file `/cygdrive/c/Program/whatis': No such file or directory
> cp: cannot create regular file `Files/GnuWin32/man/whatis': No such file or directory
> cp: cannot create regular file `/cygdrive/c/Program/whatis': No such file or directory
> cp: cannot create regular file `Files/GnuWin32/man/whatis': No such file or directory

And this looks like some problem with file names with embedded blanks
("Program Files").

> Is there really no possibility that Emacs will fix this?

I don't see any evidence of an Emacs problem here.

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[npostavs]

retitle 16722 [(old?) cygwin] `M-x man' completion doesn't handle broken `man -k' gracefully
quit

I found this post from 2014 explaining that the man package is replaced
by man-db, so the correct incantation is now `mandb' or `mandb -c' for
the first time.

https://cygwin.com/ml/cygwin/2014-07/msg00015.html
https://cygwin.com/faq/faq.html#faq.using.man

I can't reproduce the problem here, as my cygwin's man -k prints only to
stderr in this case.  Does checking exit status help?

--- i/lisp/man.el
+++ w/lisp/man.el
@@ -890,15 +890,18 @@ Man-completion-table
             ;; run differently in Man-getpage-in-background, an error
             ;; here may not necessarily mean that we'll also get an
             ;; error later.
-           (ignore-errors
-             (call-process manual-program nil '(t nil) nil
-                           "-k" (concat (when (or Man-man-k-use-anchor
-                                                  (string-equal prefix ""))
-                                          "^")
-                                        prefix))))
-         (setq table (Man-parse-man-k)))
+           (when (eq 0
+                      (ignore-errors
+                        (call-process
+                         manual-program nil '(t nil) nil
+                         "-k" (concat (when (or Man-man-k-use-anchor
+                                                (string-equal prefix ""))
+                                        "^")
+                                      prefix))))
+              (setq table (Man-parse-man-k)))))
        ;; Cache the table for later reuse.
-       (setq Man-completion-cache (cons prefix table)))
+       (when table
+          (setq Man-completion-cache (cons prefix table))))
       ;; The table may contain false positives since the match is made
       ;; by "man -k" not just on the manpage's name.
       (if section

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But `man -k' always works (to the extent we need it to) if the whatis
>> database is correctly installed.
>
> No, it doesn't.  For example, it isn't supported with this clone:
>
>   http://sourceforge.net/projects/ezwinports/files/man-1.4-bin.zip/download
>
> And, as demonstrated in this bug report, it can backfire when the
> database is not "correctly installed".

npostavs@users.sourceforge.net writes:

> I can't reproduce the problem here, as my cygwin's man -k prints only to
> stderr in this case.  Does checking exit status help?

[...]

> -         (setq table (Man-parse-man-k)))
> +           (when (eq 0
> +                      (ignore-errors
> +                        (call-process
> +                         manual-program nil '(t nil) nil
> +                         "-k" (concat (when (or Man-man-k-use-anchor
> +                                                (string-equal prefix ""))
> +                                        "^")
> +                                      prefix))))
> +              (setq table (Man-parse-man-k)))))

There was no followup on this patch, and I don't have a Windows system
to test with.  Eli, would this patch fix the problem both with the
uninstalled whereis database and the ezwinports version of man?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Wolfgang Jenkner <wjenkner@inode.at>,  16722@debbugs.gnu.org
> Date: Fri, 25 Sep 2020 12:21:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But `man -k' always works (to the extent we need it to) if the whatis
> >> database is correctly installed.
> >
> > No, it doesn't.  For example, it isn't supported with this clone:
> >
> >   http://sourceforge.net/projects/ezwinports/files/man-1.4-bin.zip/download
> >
> > And, as demonstrated in this bug report, it can backfire when the
> > database is not "correctly installed".
> 
> npostavs@users.sourceforge.net writes:
> 
> > I can't reproduce the problem here, as my cygwin's man -k prints only to
> > stderr in this case.  Does checking exit status help?
> 
> [...]
> 
> > -         (setq table (Man-parse-man-k)))
> > +           (when (eq 0
> > +                      (ignore-errors
> > +                        (call-process
> > +                         manual-program nil '(t nil) nil
> > +                         "-k" (concat (when (or Man-man-k-use-anchor
> > +                                                (string-equal prefix ""))
> > +                                        "^")
> > +                                      prefix))))
> > +              (setq table (Man-parse-man-k)))))
> 
> There was no followup on this patch, and I don't have a Windows system
> to test with.  Eli, would this patch fix the problem both with the
> uninstalled whereis database and the ezwinports version of man?

I can only test the ezwinports case: the code proposed by Noam will
cause that 'man' to return a non-zero exit status, so it sounds like
an okay solution for ezwinports.

The use case with uninstalled whatis database you could probably test
on your system, by moving the database aside or renaming it?

Thanks.

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I can only test the ezwinports case: the code proposed by Noam will
> cause that 'man' to return a non-zero exit status, so it sounds like
> an okay solution for ezwinports.
>
> The use case with uninstalled whatis database you could probably test
> on your system, by moving the database aside or renaming it?

I tried this on Debian bullseye, and "man -k" indeed had a non-zero
return code.

So I'll just apply Noam's patch and close the bug report.

Thanks for checking the ezwinports case.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16722: 24.3.50; `M-x man' does not handle case appropriately

[Drew Adams]

> Your system is mis-configured: it finds the Windows find.exe before
> (or instead) finding the Cygwin find.exe.  You should re-arrange your
> PATH.

Yes, it is my Windows PATH (which is correct for my general use on
Windows - correct order etc.), but with \ changed to / and with
drive letters replaced by /cygdrive/<DRIVE-LETTER>/.  And SPC chars
are not escaped.

`bash' apparently picks that up, as the default.  Not sure what the
right approach is to deal with this.  But at least I now understand
somewhat what's happening.

Similarly, for `exec-path' (but which includes "c:/cygwin/bin" (at
the front) and "d:/Emacs-24.5/libexec/emacs/24.5/i686-pc-mingw32"
(at the end).

> And this looks like some problem with file names with embedded blanks
> ("Program Files").

Yes; see above.

> > Is there really no possibility that Emacs will fix this?
> 
> I don't see any evidence of an Emacs problem here.

Well as I said, it used to just work, out of the box...

I see that the value of PATH inside Emacs has "c:/cygwin/bin"
at its start (because I add it there in `setup-cygwin.el').
Outside of Emacs it is not there, and it is outside Emacs where
I tried (in a bash terminal) to use `makewhatis'.

I just now added that dir to the beginning of the Windows PATH
outside Emacs, and then invoked `makewhatis' in a bash terminal,
and it built file `whatis' properly.  That fixed the completion
problem for `M-x man'.

(However, I doubt that it will be right to have that dir at the
start of my Windows PATH (for general use), so I've removed it.)

It still seems to me that this should "just work", out of
the box.

Anyway, my individual problem is solved, at least for now.  If
you are not interested in improving Emacs in some way wrt this
problem, feel free to close the bug.  And thanks to both
of you for the helpful info.