I am actually running this on Scientific Linux 7.1. The "less" that came with SL7.1 also had problems with perldoc, so I upgraded it.
rpmbuild --rebuild less-471-1.fc22.src.rpm
The new one has the same problem with perldoc too:
perlreref - Perl Regular Expressions Reference
This is a quick reference to Perl's regular expressions. For full
information see perlre and perlop, as well as the "SEE ALSO" section in
"=~" determines to which variable the regex is applied. In its absence, $_
PAGER=more perldoc perlreref
I believe this is not a bug. You should add raw-control-chars flag into your command. This option is by default turned off for some reason.
$ less -r /usr/share/man/man1/perlreref.1.gz
$ man /usr/share/man/man1/perlreref.1.gz
You can adjust less default behavior by environment variable LESS. See following example:
$ export LESS="r"
$ less /usr/share/man/man1/perlreref.1.gz
Feel free to reopen this bug if you believe that default behavior should be changed.
(In reply to Jozef Mlich from comment #2)
> Feel free to reopen this bug if you believe that default behavior should be
Using "less" this way should not involve "work arounds". It should at least match "more" in it capabilities. And this is also a regression as "less" worked fine with Perldoc under Scientific Linux 6.7.
So, missing capabilities is not a bug. Not working as expected is another thing.
Call is a Request for Enhancement if you like, but you really should fix this.
Thank you for the work around.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Hello Todd, I'm not able to reproduce this on RHEL7. On both Fedora 23
and RHEL 7 the less is run like (for the 'perldoc perlref' command):
And the documentation is readable, the color characters are not there.
Ahh, I see, reproducer is in $Summary.
'PAGER=less perldoc perlreref'
This is not regression in less, but rather change in perl documentation
generator. In RHEL6 perldoc called:
About to run /usr/bin/pod2man --lax /usr/share/perl5/pod/perlreref.pod
| nroff -man -rLL=231n
In Fedora 23:
About to call new Pod::Text::Termcap (v2.08) with options: [width 80]
Those two commands both generate different temporary files .. to be shown by
In both RHEL6+ and Fedora 23, if you don't override the PAGER variable -- this
is automatically opened by 'less -isr', which is correct default.
I tend to say it is less's NOTABUG, as we by default open the perldoc pages
correctly. What do you think?
PAGER="less -isr" perldoc perlreref
Does indeed produce a readable output, sans colors.
So the goal of this bug report would be to correct "less" such that
PAGER=less perldoc perlreref
gives the same functionality at
PAGER=more perldoc perlreref
No command line switches, all the colors, etc.
From manual page:
-r or --raw-control-chars
Causes "raw" control characters to be displayed. The default is
to display control characters using the caret notation; for
example, a control-A (octal 001) is displayed as "^A". Warning:
when the -r option is used, less cannot keep track of the actual
appearance of the screen (since this depends on how the screen
responds to each type of control character). Thus, various dis‐
play problems may result, such as long lines being split in the
You can not compare 'more' and 'less' here, because 'less' tries to be more
secure by not printing the raw input *as is* -- just to not break your screen,
so it rather "escapes" the modifying terminal sequences by default. The
'more' command on the other hand just prints everything it comes on the input.
Because we need to support terminals that do not support colors and other
terminal sequences, we can not simply turn the '-R' or '-r' option on by
default (that is probably what you request for).
Detection whether the input contains "only" color sequences, and thus it is
safe to open perldoc pages without modification would definitely cause
performance lost (whole input must be read in advance).
What could be done, at least *I* think, is to drop the escape sequences
entirely (by default), as I can imagine that is what people want the most of
the time, but the question is what to do with other "binary" characters.
Let me try to ask upstream.
Ok, I was confused because I (somehow?) reproduced this on F23 too. Taking
into account that I must have done something wrong before (I'm not able to
reproduce it on F23 now) question from Petr was, why this is reported against
Fedora ... and the reason was because you installed Fedora's less on
RHEL7-like distribution, and it did not help. But this is not about less.
In RHEL7, perldoc does *not* export LESS=-R variable, and thus even the less
from Fedora 22 is not able to fix the issue for you. The obvious thing
you could is to request fix for perldoc, but you probably can export that
variable yourself, too.
(In reply to Pavel Raiskup from comment #10)
> What could be done, at least *I* think, is to drop the escape sequences
> entirely (by default), as I can imagine that is what people want the most of
> the time, but the question is what to do with other "binary" characters.
> Let me try to ask upstream.
Usually I would close this bug UPSTREAM with reference to upstream tracker,
but there is no upstream mailing list or bugzilla; so I keep it open here,
until the upstream reaction to this idea (then I'll close this UPSTREAM or
=== Copy-Paste my question for Mark ===
On Thursday, April 21, 2016 1:11:40 PM CEST Mark Nudelman wrote:
> I'm not sure I understand the question. When you say "to escape
> terminal color sequences, or whether we should rather drop them
> completely", are you referring to behavior by less or by perldoc?
The original question was whether we should escape terminal color sequences
"by default". Example:
LESSOPEN='|| bash -c "echo -e \"\e[0;32mHello world\e[0m\""' less /etc/passwd
This command ^^^ produces output like:
bash -c "echo -e \"\e[0;32mHello world\e[0m\"" | less
But I doubt this is useful for somebody. To me, it would be a lot more
useful if less by default produced readable output for such *text* files.
If somebody still wanted to escape the color sequences, that could be
optional feature. Would that make sense?
NOTE: I can understand that we need to escape binary files ... but there's
already implemented prompt:
"FILE" may be a binary file. See it anyway?
.. so I'm not proposing to change behavior for binary files.