Description of problem: Running man on a local man page file, produces different results, depending on whether you pass the file to the -l flag or cat it and pipe it and then reference to it using a '-'. Version-Release number of selected component (if applicable): man 2.7.1 How reproducible: always Steps to Reproduce: 1. find a valid man page file (you can extract one from /usr/share/man/man1) 2. man -P cat -l rpmlint.1 3. cat rpmlint.1 | man -P cat -l - Actual results: first man command renders the man page properly to the whole width of the terminal second man command renders the man page with a fixed with of what looks like 80 characters. Expected results: Both commands should render the man page the same way, to fit the whole screen. Additional info: Possibly related: https://bugzilla.redhat.com/show_bug.cgi?id=1244190 Same 'not-fitting' effect observed. I am setting the severity high, because the broken variant is how lessopen.sh preprocesses compressed man pages for display. Thus a lot of users will be coming in contact with it.
I ment lesspipe.sh
This works for me. I suspect that the COLUMNS environment variable is set incorrectly. Please could you confirm? bash normally sets it, and it is specified by POSIX (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03), but perhaps some shells or configurations do not. The algorithm used by man to determine the line length is as follows: 1) If MANWIDTH is set to a number greater than 0, use that. 2) If COLUMNS is set to a number greater than 0, use that. 3) If either stdin or stdout is a tty and the TIOCGWINSZ ioctl returns a non-zero ws_col, use that. 4) Otherwise, use 80. If this doesn't help, please add the --debug option to man in the two contrasting cases you give and attach the output.
I am using zsh, On both bash and zsh, echo $COLUMNS returns the current number of columns (80 on new terminal, 211 on maximize) On both bash and zsh, $MANWIDTH is undefined/empty. How can I verify the third point?
In that case please just show me the debug output requested earlier.
Well, this is strange. I tried it again today, and it works properly in both zsh and bash... with either command. I am quite sure it didn't work correctly yesterday. But I still get the bad behaviour, when I use 'less <manpage>.gz' directly, with these changes: https://bugzilla.redhat.com/show_bug.cgi?id=1241543 Which is weird, because it uses exactly the same commands that seem to work properly. Can you reproduce the bug using 'less <manpage>.gz'? I have trouble extracting the debug info from the man command in lesspipe.sh. I can reproduce it using 'less <manpage>.gz' in both bash and zsh. Though all other alternatives seem to be working.
Created attachment 1065809 [details] Try to get terminal width from /dev/tty
Well, the situation you describe makes more sense anyway. Could you please try the attached patch?
I tested the patch, and it seems to resolve the issue. 'less rpmlint.1', 'less rpmlint.1.gz' and 'man rpmlint' all produce output of the same width. The last difference is that 'less rpmlint.1[.gz]' renders the man page without any bold text. Do you have an idea what could be causing this? To my understanding, it should be possible to render it with bold sections, as less is the man pager, and it works in man. Also, this probably isn't a bug, but just to be sure. The 'man <manpage>' / 'less <manpage>' output don't fit the terminal perfectly, it appears to be one column shorter at 80 columns and 6 columns shorter at 211 columns. Could this be an arithmetic error? I ran man inside an Ubuntu Docker Image and observed the same behavior. Thank you for your effort!
Thanks for testing! I added a NEWS entry and pushed this to git master: http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=80f1dc0fe23b9f6ec9eb2ea7c5a2b654e9840dd9 Regarding bold text, see man(1): MAN_KEEP_FORMATTING Normally, when output is not being directed to a terminal (such as to a file or a pipe), formatting characters are discarded to make it easier to read the result without special tools. How- ever, if $MAN_KEEP_FORMATTING is set to any non-empty value, these formatting characters are retained. This may be useful for wrappers around man that can interpret formatting charac- ters. As for the line length, man has always left a little bit of a right margin, I think for aesthetic reasons. The current computation is min(line_length * 39 / 40, line_length - 2).
Thanks Colin, backported. f22: http://pkgs.fedoraproject.org/cgit/man-db.git/commit/?h=f22&id=4ea2e0ba026cde0ae91f3adae30b0eb073594383 f23: http://pkgs.fedoraproject.org/cgit/man-db.git/commit/?h=f23&id=8931f708e3d56bf5c9263b2428b52d0d4bc37a64 master: http://pkgs.fedoraproject.org/cgit/man-db.git/commit/?id=f806a0bbc5f5a36327de25e4917b752db9717946
man-db-2.7.1-9.fc23 has been submitted as an update to Fedora 23. https://bugzilla.redhat.com/show_bug.cgi?id=1255930
man-db-2.7.1-8.fc22 has been submitted as an update to Fedora 22. https://bugzilla.redhat.com/show_bug.cgi?id=1255930
man-db-2.7.1-8.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update man-db'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14122
man-db-2.7.1-9.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update man-db'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14121
man-db-2.7.1-9.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
man-db-2.7.1-8.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.