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

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

[trentbuck]

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]

bug#5347: marked as done (23.1; M-x man: misreports absent man(1) as absent manpage.)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Your message dated Sat, 09 Jan 2010 16:02:24 +0200
with message-id <83skaf8jgv.fsf@gnu.org>
and subject line Re: bug#5347: 23.1; M-x man: misreports absent man(1) as absent manpage.
has caused the Emacs bug report #5347,
regarding 23.1; M-x man: misreports absent man(1) as absent manpage.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
5347: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5347
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 7439 bytes --]

From: trentbuck@gmail.com
To: bug-gnu-emacs@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)
Message-ID: <4b48732e.e701be0a.4cf2.3e5c@mx.google.com>

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]




[-- Attachment #3: Type: message/rfc822, Size: 2713 bytes --]

From: Eli Zaretskii <eliz@gnu.org>
To: trentbuck@gmail.com, 5347-done@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
Message-ID: <83skaf8jgv.fsf@gnu.org>

> Date: Sat, 09 Jan 2010 04:14:38 -0800 (PST)
> From: trentbuck@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.

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

[Trent W. Buck]

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)

bug#5347: marked as done (23.1; M-x man: misreports absent man(1) as absent manpage.)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Your message dated Sun, 10 Jan 2010 06:05:28 +0200
with message-id <83pr5i8v07.fsf@gnu.org>
and subject line Re: bug#5347: 23.1; M-x man: misreports absent man(1) as absent manpage.
has caused the Emacs bug report #5347,
regarding 23.1; M-x man: misreports absent man(1) as absent manpage.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
5347: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5347
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 7439 bytes --]

From: trentbuck@gmail.com
To: bug-gnu-emacs@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)
Message-ID: <4b48732e.e701be0a.4cf2.3e5c@mx.google.com>

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]




[-- Attachment #3: Type: message/rfc822, Size: 3037 bytes --]

From: Eli Zaretskii <eliz@gnu.org>
To: "Trent W. Buck" <trentbuck@gmail.com>
Cc: 5347-done@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
Message-ID: <83pr5i8v07.fsf@gnu.org>

> Date: Sun, 10 Jan 2010 14:05:39 +1100
> From: "Trent W. Buck" <trentbuck@gmail.com>
> Cc: 5347@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.

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

[Trent W. Buck]

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).

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

[Eli Zaretskii]

> Date: Sun, 10 Jan 2010 15:30:38 +1100
> From: "Trent W. Buck" <trentbuck@gmail.com>
> Cc: 5347@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)

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

[Trent W. Buck]

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.

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

[Juri Linkov]

>> 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/

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

[Drew Adams]

> >> 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.