Bug 1255930 - 'man -P cat -l' behaves differently if the input is from stdin or from a file
'man -P cat -l' behaves differently if the input is from stdin or from a file
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: man-db (Show other bugs)
22
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Nikola Forró
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-21 20:21 EDT by Viktor Jancik
Modified: 2016-01-31 21:25 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.7.1-8.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-01 19:22:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Try to get terminal width from /dev/tty (2.15 KB, patch)
2015-08-22 07:15 EDT, Colin Watson
no flags Details | Diff

  None (edit)
Description Viktor Jancik 2015-08-21 20:21:28 EDT
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.
Comment 1 Viktor Jancik 2015-08-21 20:42:08 EDT
I ment lesspipe.sh
Comment 2 Colin Watson 2015-08-21 20:55:58 EDT
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.
Comment 3 Viktor Jancik 2015-08-21 21:41:16 EDT
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?
Comment 4 Colin Watson 2015-08-22 04:35:58 EDT
In that case please just show me the debug output requested earlier.
Comment 5 Viktor Jancik 2015-08-22 06:49:46 EDT
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.
Comment 6 Colin Watson 2015-08-22 07:15:19 EDT
Created attachment 1065809 [details]
Try to get terminal width from /dev/tty
Comment 7 Colin Watson 2015-08-22 07:16:00 EDT
Well, the situation you describe makes more sense anyway.  Could you please try the attached patch?
Comment 8 Viktor Jancik 2015-08-22 09:16:31 EDT
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!
Comment 9 Colin Watson 2015-08-22 10:57:27 EDT
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).
Comment 11 Fedora Update System 2015-08-24 11:49:11 EDT
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
Comment 12 Fedora Update System 2015-08-24 11:51:24 EDT
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
Comment 13 Fedora Update System 2015-08-24 17:54:14 EDT
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
Comment 14 Fedora Update System 2015-08-24 17:56:57 EDT
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
Comment 15 Fedora Update System 2015-08-27 13:57:44 EDT
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.
Comment 16 Fedora Update System 2015-09-01 19:22:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.