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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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 [hidden email]-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'



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Wolfgang Jenkner
> From: Wolfgang Jenkner <[hidden email]>
> Date: Sat, 15 Feb 2014 18:17:08 +0100
> Cc: [hidden email]
>
> 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?).



Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Jenkner
In reply to this post by Drew Adams
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



Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Jenkner
In reply to this post by Eli Zaretskii
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




Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Wolfgang Jenkner
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Wolfgang Jenkner
> From: Wolfgang Jenkner <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Jenkner
In reply to this post by 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.

Wolfgang



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> Cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky-2
In reply to this post by Drew Adams
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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> 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".

[hidden email] 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> 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