-=| Thomas Schoepf, 15.04.2004 11:27:52 +0200 |=-
> without additional information, especially the perldoc file that
> contains those characters, this bug report is not very useful.
-=| Thomas Schoepf, 10.12.2004 16:13:17 +0100 |=-
> does this problem still occur?
Since perl 5.20' perldoc command switched from "man" rendering to
"term" rendering, it is quite easy to reproduce the problem:
perldoc perlcn
In gnome-terminal, with UTF-8 locale that gives me some Chinese text
with section headings containing visible ANSI escape sequences.
Compare with:
perldoc perlcn | more
or
perldoc perlcn | most # requires package 'most' to be installed
or
perldoc perlcv | less -R
> Besides that, I have doubts this is really a bug in less. Less is
> using some system's functions to determine whether a given character
> is "printable" or not. If the perldoc contains national language
> subset characters, but your locale is set to use the ASCII character
> set then it's inevitable that less shows those Escape sequences
> (they are used to display "control" characters).
I don't think this is what is happening since the locale/terminal are
fully UTF-8-aware.
> The option -R just forces less to output the characters no matter what
> (read: at your own risk).
I think you mean "-r" as dangerous. From less(1):
-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". Warn‐
ing: 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 display problems may result, such as long lines being
split in the wrong place.
-R or --RAW-CONTROL-CHARS
Like -r, but only ANSI "color" escape sequences are output in
"raw" form. Unlike -r, the screen appearance is maintained
correctly in most cases. ANSI "color" escape sequences are
sequences of the form:
ESC [ ... m
where the "..." is zero or more color specification characters
For the purpose of keeping track of screen appearance, ANSI
color escape sequences are assumed to not move the cursor.
You can make less think that characters other than "m" can end
ANSI color escape sequences by setting the environment vari‐
able LESSANSIENDCHARS to the list of characters which can end
a color escape sequence. And you can make less think that
characters other than the standard ones may appear between the
ESC and the m by setting the environment variable LESSANSIMID‐
CHARS to the list of characters which can appear.
So as I uderstand it, "-r" is dangerous, "-R" is safe.
What I am trying to say is that having -R be the default would be very
nice and should be safe.
Cheers,
dam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
