Bug 1258741 - RFE: "PAGER=less perldoc perlreref" escapes color sequences, drop them or interpret them
Summary: RFE: "PAGER=less perldoc perlreref" escapes color sequences, drop them or int...
Alias: None
Product: Fedora
Classification: Fedora
Component: less
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Matej Mužila
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1329059
TreeView+ depends on / blocked
Reported: 2015-09-01 07:33 UTC by Todd
Modified: 2019-03-14 07:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1329059 (view as bug list)
Last Closed: 2015-09-01 07:50:34 UTC
Type: Bug

Attachments (Terms of Use)

Description Todd 2015-09-01 07:33:38 UTC
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
    this document.

    "=~" determines to which variable the regex is applied. In its absence, $_
    is used. 

PAGER=more perldoc perlreref

works fine

Comment 1 Jozef Mlich 2015-09-01 07:50:34 UTC
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

Comment 2 Jozef Mlich 2015-09-01 07:52:48 UTC
Feel free to reopen this bug if you believe that default behavior should be changed.

Comment 3 Todd 2015-09-02 04:32:04 UTC
(In reply to Jozef Mlich from comment #2)
> Feel free to reopen this bug if you believe that default behavior should be
> changed.

Hi Jozef,

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.

Many thanks,

Comment 5 Fedora Admin XMLRPC Client 2016-03-24 18:01:05 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Pavel Raiskup 2016-04-20 08:15:25 UTC
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):

  '/usr/bin/less -isr'

And the documentation is readable, the color characters are not there.

Comment 7 Pavel Raiskup 2016-04-20 08:17:38 UTC
Ahh, I see, reproducer is in $Summary.

'PAGER=less perldoc perlreref'

Comment 8 Pavel Raiskup 2016-04-20 08:27:00 UTC
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?

Comment 9 Todd 2016-04-20 19:51:35 UTC
Hi Pavel,

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.


Comment 10 Pavel Raiskup 2016-04-21 04:43:17 UTC
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
              wrong place.

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.

Comment 11 Pavel Raiskup 2016-04-21 07:26:52 UTC
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

Comment 12 Pavel Raiskup 2016-10-26 05:28:21 UTC
=== 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:

    ESC[0;32mHello worldESC[0m

Similarly does:

    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.

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