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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Trent W. Buck" <trentbuck <at> gmail.com>
Cc: 5347 <at> debbugs.gnu.org
Subject: 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)

Previous Next

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