> from groff-base 1.18.1.1-7 we have:
> $ echo '.BR foo bar' |
> > 2>>/dev/null groff -te -msafer -mtty-char -mm -Tascii |
> > fgrep f | cat -v
> ^[[1mfoo^[[22mbar
> $
>
> Apparently with groff-base 1.18.1.1-7, -Tascii is outputting ANSI
> escape sequences, and this of course breaks all kinds of stuff (e.g.
> this no longer works on dumb line printers and other devices that
> perfectly well understand ^H, ^I, ^L and printable ASCII characters,
> but know nothing of ANSI escape sequences; this similarly breaks
> stuff passed to less or col -b, etc., generally resulting in quite a
> mess).
This is an ooooold issue. groff 1.18 has been released 4 years ago!
> This works fine on oldstable (woody) groff-base 1.17.2-15.woody.1 as
> seen here:
> $ echo '.BR foo bar' |
> > 2>>/dev/null groff -te -msafer -mtty-char -mm -Tascii |
> > fgrep f | cat -v
> f^Hfo^Hoo^Hobar
> $
>
> If one wants ANSI escape sequences, perhaps there should be a
> -Tansi, but please, -Tascii should continue to only generate
> printable ASCII characters and well defined common ASCII control
> codes (e.g. ^H, ^I, ^L), and should *not* generate ANSI escape
> sequences, as the actions of these escape sequences are not defined
> in the ASCII character set.
I strongly disagree. To get bold characters with ^H was and is and
will be a hack. How do you come to the conclusion that embolding of a
character string with ^H is in any way standardized in ASCII? ^H is a
backspace, nothing else. AFAIK there is *no* standard which defines
this behaviour, whereas SGR is defined in ISO 6429 (and ECMA-48).
The solution to your problem is the very first item in groff's
`PROBLEMS' files. For your convenience, I'm pasting it below.
Werner
======================================================================
* Displaying a man page on a terminal with/without my favourite pager
only gives garbage.
groff by default now uses SGR escape sequences (`ANSI color') to
control the display attributes (bold, underlined, colour) on TTYs.
Some terminals (e.g. `kterm') don't understand SGR, and some pagers
(e.g. older versions of `less' or `less' without the -R option) don't
understand SGR either. There are three solutions to fix this, in order
of preference; please read the grotty man page for more details.
The fourth and probably best option is to update your terminal program
and pager to versions which can handle SGR.
1. Set the GROFF_NO_SGR environment variable.
2. Pass option -c to grotty (this is, add `-P-c' to groff's command
line options).
3. Append the following fragment to the `troffrc' file:
--- start ---
.if n \{\
. nr _C \n(.C
. cp 0
.
. \" The following code sets a top-of-page trap to disable grotty's TTY
. \" mode. Since neither \X nor .output can be used before the first
. \" page has started, we must use a trap. To make it work with troff's
. \" -o option, we wait until the first printed page.
.
. de [EMAIL PROTECTED]
. .
.
. rn wh [EMAIL PROTECTED]
.
. \" The stand-alone version. If no other trap is set, we can safely
. \" insert the truncated vertical space caused by the trap (if any).
. \" Otherwise we assume that the document's main macro package takes
. \" care of that. As soon as the trap has been executed, it is removed.
. de1 [EMAIL PROTECTED]
. if \\n[.P] \{\
. if (\\n[.t] == \\n[.p]) \{\
. rn [EMAIL PROTECTED] wh
. rm [EMAIL PROTECTED]
. wh 0
. sp \\n[.trunc]
. nop \X'tty: sgr 0'
. sp -1
. \}\}
. .
.
. [EMAIL PROTECTED] 0 [EMAIL PROTECTED]
.
. \" The piggyback version to be appended to macros planted with the
. \" modified `wh' request.
. de1 [EMAIL PROTECTED]
. if \\n[.P] \{\
. rn [EMAIL PROTECTED] wh
. ds [EMAIL PROTECTED]
. nop \X'tty: sgr 0'
. sp -1
. \}
. .
.
. \" We redefine the `wh' request so that [EMAIL PROTECTED]' is appended to
. \" the trap macro.
. de1 wh
. am1 \\$2 [EMAIL PROTECTED]
. [EMAIL PROTECTED]
. [EMAIL PROTECTED]
. [EMAIL PROTECTED] \\$1 \\$2
. .
.
. cp \n[_C]
.\}
--- end ---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
