GNU bug report logs - #5347
23.1; M-x man: misreports absent man(1) as absent manpage.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5347 in the body.
You can then email your comments to 5347 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: trentbuck <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; M-x man: misreports absent man(1) as absent manpage.
Date: Sat, 09 Jan 2010 04:14:38 -0800 (PST)

On my system, man(1) is not present, but a manpage was.  M-x man RET
pastebinint RET claimed that the manPAGE was missing, when actually
man(1) is what was missing.  M-x woman RET pastebinint RET works.

In GNU Emacs 23.1.1 (i486-pc-linux-gnu)
 of 2009-11-02 on raven, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=no' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  rcirc-track-minor-mode: t
  xterm-mouse-mode: t
  savehist-mode: t
  icomplete-mode: t
  partial-completion-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
SPC t o SPC d a r c s . c a b a l SPC t o SPC f i x 
SPC t h a t , DEL RET C-x ESC O A C-c C-@ a p t - g 
e t SPC s o u r c e SPC d o e s n ' t SPC n e e d SPC 
t o o SPC DEL DEL DEL DEL r o o t RET ESC a C-u C-c 
C-@ E a c h SPC v l a n SPC a p p e a r s SPC a s SPC 
a SPC s e p a r a t e SPC i n t e r f a c e ESC b ESC 
b ESC b ESC b ESC b ESC b ESC d t a g g e d SPC i n 
t e r f a c e RET ESC a C-x ESC O B I SPC g e t SPC 
t h e SPC s a m e SPC p r o b l e m SPC w i t h SPC 
H E A D , SPC c h e c k i n g SPC - h s SPC n o w RET 
ESC [ 5 ~ ESC > C-c C-@ ESC x m a n RET p a s t e b 
i n i t RET ESC x C-g ESC x w o m a n RET ESC O A RET 
C-x ESC O A ESC x m a n RET ESC O A RET C-h e C-@ ESC 
O A ESC O A ESC O A ESC w ESC > ESC x r e p o r t SPC 
e m a c s SPC b u g RET

Recent messages:
Building list of manual directory expansions...
Building completion list of all manual topics...
uncompressing pastebinit.1.gz...done
WoMan formatting buffer...done in 0 seconds
Invoking man pastebinit in the background
Please wait: formatting the pastebinit man page...
pastebinit man page formatted
error in process sentinel: Man-bgproc-sentinel: Can't find the pastebinit manpage
error in process sentinel: Can't find the pastebinit manpage
Mark set [2 times]

Message #10 received at 5347-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: trentbuck <at> gmail.com, 5347-done <at> debbugs.gnu.org
Subject: Re: bug#5347: 23.1;
	M-x man: misreports absent man(1) as absent manpage.
Date: Sat, 09 Jan 2010 16:02:24 +0200

> Date: Sat, 09 Jan 2010 04:14:38 -0800 (PST)
> From: trentbuck <at> gmail.com
> Cc: 
> 
> On my system, man(1) is not present, but a manpage was.  M-x man RET
> pastebinint RET claimed that the manPAGE was missing, when actually
> man(1) is what was missing.  M-x woman RET pastebinint RET works.

"M-x man" works by invoking man(1), so it cannot work without one
installed.  "M-x woman" (WO == without) does not need man(1),
therefore it still works.

So this is expected.  If you don't have man(1) installed, you should
use WoMan to begin with.

Message #13 received at 5347 <at> debbugs.gnu.org (full text, mbox):

From: "Trent W. Buck" <trentbuck <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5347 <at> debbugs.gnu.org
Subject: Re: bug#5347: 23.1; M-x man: misreports absent man(1) as absent
	manpage.
Date: Sun, 10 Jan 2010 14:05:39 +1100

reopen 5347
thanks

Eli Zaretskii wrote:
>> On my system, man(1) is not present, but a manpage was.  M-x man
>> RET pastebinint RET claimed that the manPAGE was missing, when
>> actually man(1) is what was missing.  M-x woman RET pastebinint RET
>> works.
>
> "M-x man" works by invoking man(1), so it cannot work without one
> installed.  "M-x woman" (WO == without) does not need man(1),
> therefore it still works.

I realize that.  This issue is because M-x man RET foo RET reports

    error in process sentinel: Can't find the foo manpage

but it should report something like

    error in process sentinel: Can't find man(1)

Message #20 received at 5347-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Trent W. Buck" <trentbuck <at> gmail.com>
Cc: 5347-done <at> debbugs.gnu.org
Subject: Re: bug#5347: 23.1;
	M-x man: misreports absent man(1) as absent manpage.
Date: Sun, 10 Jan 2010 06:05:28 +0200

> Date: Sun, 10 Jan 2010 14:05:39 +1100
> From: "Trent W. Buck" <trentbuck <at> gmail.com>
> Cc: 5347 <at> debbugs.gnu.org
> 
> reopen 5347
> thanks
> 
> Eli Zaretskii wrote:
> >> On my system, man(1) is not present, but a manpage was.  M-x man
> >> RET pastebinint RET claimed that the manPAGE was missing, when
> >> actually man(1) is what was missing.  M-x woman RET pastebinint RET
> >> works.
> >
> > "M-x man" works by invoking man(1), so it cannot work without one
> > installed.  "M-x woman" (WO == without) does not need man(1),
> > therefore it still works.
> 
> I realize that.  This issue is because M-x man RET foo RET reports
> 
>     error in process sentinel: Can't find the foo manpage
> 
> but it should report something like
> 
>     error in process sentinel: Can't find man(1)

It cannot know.

Message #23 received at 5347 <at> debbugs.gnu.org (full text, mbox):

From: "Trent W. Buck" <trentbuck <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5347 <at> debbugs.gnu.org
Subject: Re: bug#5347: 23.1; M-x man: misreports absent man(1) as absent
	manpage.
Date: Sun, 10 Jan 2010 15:30:38 +1100

Eli Zaretskii wrote:
>> I realize that.  This issue is because M-x man RET foo RET reports
>>     error in process sentinel: Can't find the foo manpage
>> but it should report something like
>>     error in process sentinel: Can't find man(1)
>
> It cannot know.

I don't understand why.  Surely it can (executable-find "man") or even
simply check the exit status (which will be 126 or 127 if man isn't
executable).

Message #26 received at 5347 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Trent W. Buck" <trentbuck <at> gmail.com>
Cc: 5347 <at> debbugs.gnu.org
Subject: Re: bug#5347: 23.1;
	M-x man: misreports absent man(1) as absent manpage.
Date: Sun, 10 Jan 2010 19:48:34 +0200

> Date: Sun, 10 Jan 2010 15:30:38 +1100
> From: "Trent W. Buck" <trentbuck <at> gmail.com>
> Cc: 5347 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> >> I realize that.  This issue is because M-x man RET foo RET reports
> >>     error in process sentinel: Can't find the foo manpage
> >> but it should report something like
> >>     error in process sentinel: Can't find man(1)
> >
> > It cannot know.
> 
> I don't understand why.  Surely it can (executable-find "man") or even
> simply check the exit status (which will be 126 or 127 if man isn't
> executable).

But "M-x man" does not just run man(1), it runs a whole pipeline of
different commands, including Sed and Awk.  And that's just by
default; some parts of the pipeline can be customized to invoke other
commands.  Testing each one of them via executable-find would be
impractical.  Testing for exit status of 127 or 126 is
system-dependent, so it won't work on all systems.  And since "M-x
man" invokes the pipeline asynchronously, all it sees is an empty
buffer or buffer with contents it doesn't expect.

Why is the use-case of having man pages but not man(1) so important
that it's worth catering to?

Maybe it would be good enough to change

		(error "Can't find the %s manpage" args)
into
		(error "Can't find the %s manpage or no man(1)" args)

Message #29 received at 5347 <at> debbugs.gnu.org (full text, mbox):

From: "Trent W. Buck" <trentbuck <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5347 <at> debbugs.gnu.org
Subject: Re: bug#5347: 23.1; M-x man: misreports absent man(1) as absent
	manpage.
Date: Mon, 11 Jan 2010 10:59:31 +1100

Eli Zaretskii wrote:
> Why is the use-case of having man pages but not man(1) so important
> that it's worth catering to?

I was merely being pedantic re "cannot know" versus "not worth the
effort".  The original case arose because I forgot what system I was
on and ran man instead of woman, and the error briefly confused me.

A peonland solution would simply be to put in my .emacs:

    (unless (executable-find "man")
      (defalias 'man 'woman))

> Maybe it would be good enough to change
>
> 		(error "Can't find the %s manpage" args)
> into
> 		(error "Can't find the %s manpage or no man(1)" args)

Yup, that'd be fine.

Message #32 received at 5347 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Trent W. Buck" <trentbuck <at> gmail.com>
Cc: 5347 <at> debbugs.gnu.org
Subject: Re: bug#5347: 23.1;
	M-x man: misreports absent man(1) as absent manpage.
Date: Mon, 11 Jan 2010 02:52:07 +0200

>> Maybe it would be good enough to change
>>
>> 		(error "Can't find the %s manpage" args)
>> into
>> 		(error "Can't find the %s manpage or no man(1)" args)
>
> Yup, that'd be fine.

No, please don't change this.  A new error message is confusing.
It's not clear what "no man(1)" does mean.  The current message is good
for normal cases when the man executable and its filters are present
on the system.  Please either try to detect the fact that the man
executable is missing and display a separate error message, or leave
the current message unchanged.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Message #35 received at 5347 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>, <5347 <at> debbugs.gnu.org>,
	"'Trent W. Buck'" <trentbuck <at> gmail.com>
Subject: RE: bug#5347: 23.1;
	M-x man: misreports absent man(1) as absent manpage.
Date: Sun, 10 Jan 2010 21:34:51 -0800

> >> Maybe it would be good enough to change
> >>
> >> 		(error "Can't find the %s manpage" args)
> >> into
> >> 		(error "Can't find the %s manpage or no man(1)" args)
> >
> > Yup, that'd be fine.
> 
> No, please don't change this.  A new error message is confusing.
> It's not clear what "no man(1)" does mean.  The current 
> message is good
> for normal cases when the man executable and its filters are present
> on the system.  Please either try to detect the fact that the man
> executable is missing and display a separate error message, or leave
> the current message unchanged.

FWIW, I agree with Juri. That is not the right fix (if a fix is needed) - that
message is less clear than the original one.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.