Re: texinfo-5.9.90 pretest available

[Gavin Smith]

On 25 February 2015 at 20:20, Eli Zaretskii <address@hidden> wrote:
>> Date: Wed, 25 Feb 2015 19:31:34 +0000
>> From: Gavin Smith <address@hidden>
>> Cc: Karl Berry <address@hidden>, Texinfo <address@hidden>
>>
>> > However, I don't see why the HAVE_FORK branch should behave
>> > differently: it doesn't check the exit status of 'man', AFAICS, just
>> > that the text it returned is non-empty.  And the Unix 'man' also says
>> > "No manual entry for FiLe-M" in this case.
>> >
>> > Is this perhaps an issue with stdout vs stderr?  The version of 'man'
>> > I use outputs this message to stdout.  If this is the reason for the
>> > difference in behavior, then how about adding to the HAVE_FORK branch
>> > a test of the exit status?  Then having that in the popen branch will
>> > be justified.
>>
>> I had the same results as you when I put a "man" executable earlier in
>> the path that printed a message to stdout (including the test
>> failures). I've made the change you suggested.
>
> Thanks!

I found a problem with this solution. On my system I happen to have
duplicate man pages for "popen" for some reason. Running "man -a
popen" does open "less" and show the man page, but it also puts an
error message to stderr:

bash $man -a popen
Man page /usr/share/man/man3p/popen.3.gz is identical to
/usr/share/man/man3/popen.3.gz
No manual entry for popen
bash $echo $?
1
bash $man --version
man, version 1.6g

I don't know why a duplicate man page was worthy of a failing exit
status, but we should cope with this behaviour. What comes to mind is
checking the exit status first, and then also checking the length of
output - if it contains more than one or two newlines it is probably a
real man page, and not an error message sent to stdout.