man command not working in lynxcgi script
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libpipeline (Ubuntu) |
Fix Released
|
Medium
|
Colin Watson | ||
man-db (Ubuntu) |
Fix Released
|
Medium
|
Colin Watson |
Bug Description
I have made slight tweaks to the w3mman2html.cgi script supplied with w3m so that it is usable by other browsers, in particular lynx and firefox (I also use the script with lynx under windows/cygwin). However, an un-tweaked version will demonstrate this problem. Through Ubuntu 11.10, I was able to execute the script in lynx using the lynxcgi protocol. In Ubuntu 12.04, the script still works for w3m, of course, and for firefox; however, it no longer works for lynx. In order to try to narrow down the source of the problem, I altered the cgi script so that the command it issued wound up as:
/usr/bin/man -d apropos 2>temp.mand
(Note that this problem is not restricted to the apropos man page; all pages show the same results.)
Comparing the temp.mand files, which I am attaching to this report, the successful w3m run produces a 389-line log. The unsuccesful lynx version produces a 388-line log; the first 379 are identical to w3m, followed by an insertion:
gzip: standard input: Bad file descriptor
They then compare equal on the next line, but then 4 lines of w3m (indicating success) are replaced with 2 lines for lynx (indicating failure). The final 5 lines of each file then compare equal. Here are the differences reported by diff:
380d379
< gzip: standard input: Bad file descriptor
382,383c381,384
< cat-saver exited with status 1
< unlinking temporary cat
---
> cat-saver exited with status 0
> fixing temporary cat's mode
> renaming temporary cat to /var/cache/
> setting modtime on cat file /var/cache/
To get to this situation, the lynx.cfg file needs the following:
TRUSTED_LYNXCGI: /usr/lib/
LYNXCGI_
LYNXCGI_
The command to demonstrate the problem would then be:
lynx lynxcgi:
The command for w3m is: w3mman apropos
It is, of course, possible that the problem lies not with man-db but with lynx (it seems very unlikely to be with the cgi script). However, since man debug clearly shows a difference between the results of the script when run under one vs. the other, I am starting by reporting it as a man-db bug.
Thanks for your report, and sorry for my delay!
The distinguishing feature here is that lynx closes the CGI script's standard input. As a result, at some point man does roughly:
last_input = open (filename, O_RDONLY);
dup2 (last_input, 0);
close (last_input);
But the "open" returns 0, since that's the first available file descriptor, so everything is now very confused. libpipeline needs to tolerate this situation.