Hide Forgot
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: ESC[1mNAMEESC[0m perlreref - Perl Regular Expressions Reference ESC[1mDESCRIPTIONESC[0m 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. ESC[1mOPERATORSESC[0m "=~" determines to which variable the regex is applied. In its absence, $_ is used. PAGER=more perldoc perlreref works fine
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 > 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, -T
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): '/usr/bin/less -isr' 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 less. 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?
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. -T
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.
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 NOTABUG).
=== 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.