When I do in my terminal a, for instance,
I can see that some of the texts are rendered in different colours, based on the control characters which
man produces in its output, while some are not.
For instance, the terminal displays
NAME tr <E2><80><93> translate characters
from which I conclude, that the hex sequence E28093 is not interpreted. My guess is that this this is a certain unicode character sequence (maybe for a long dash), but I don't understand why it is not shown.
TERM variable is set to xterm-256color and the
LANG environment variable is set to en_GB.utf8 and I don't have neither a
PAGER nor a
MANPAGER variable defined, which means that
man pipes to
However, I have defined the variable
LESS, which provides default options for
less. It's value is
-A --quit-if-one-screen --LONG-PROMPT -X -R; but I don't see, how this could explain the behaviour. Furthermore, even when I explicitly use a different pager, i.e.
MANPAGER=more man tr
the output is the same.
Unicode characters seem to be displayed fine. For instance, if I do in the command line (which is zsh) a
I see as output an
This happens with both Terminal.app and iTerm2. The font being used is Monaco,
BTW, on request by user
mmmmmm, I encluse here a screenshot of the output produced by
man -d tr:
I did a
man tr | tee tmp/man_tr.txt xxd tmp/mat_tr.txt
to see the exact hex code produced by tr. The first couple of lines look like this:
00000000: 5452 2831 2920 2020 2020 2020 2020 2020 TR(1) 00000010: 2020 2020 2020 2020 2020 2020 2047 656e Gen 00000020: 6572 616c 2043 6f6d 6d61 6e64 7320 4d61 eral Commands Ma 00000030: 6e75 616c 2020 2020 2020 2020 2020 2020 nual 00000040: 2020 2020 2020 2020 2020 2054 5228 3129 TR(1) 00000050: 0a0a 4e08 4e41 0841 4d08 4d45 0845 0a20 ..N.NA.AM.ME.E. 00000060: 2020 2020 7408 7472 0872 20e2 8093 2074 t.tr.r ... t 00000070: 7261 6e73 6c61 7465 2063 6861 7261 6374 ranslate charact 00000080: 6572 730a 0a53 0853 5908 594e 084e 4f08 ers..S.SY.YN.NO. 00000090: 4f50 0850 5308 5349 0849 5308 530a 2020 OP.PS.SI.IS.S. 000000a0: 2020 2074 0874 7208 7220 5b2d 082d 4308 t.tr.r [-.-C. 000000b0: 4363 0863 7308 7375 0875 5d20 5f08 735f Cc.cs.su.u] _.s_
We can see the ominous byte sequence e28093 occuring in the line at offset 60. What on earth is this? It can't be a UTF-8 sequence (there are no 3-byte-sequences starting with E2).
Furthermore these ghost codes don't appear on every man page. I see it with i.e.
man cat, but they don't show with
man zsh or
man bash..... But there is a system in it:
I have installed via Homebrew the Gnu tools for the Mac. For installing them, there are two options: (1) Have them replace the original files, i.e. GNU-tr replaces the MacOS-tr, or (2) leave the original binaries unchanged and install the GNU tools under a new name, i.e. the GNU-tr is now named
/usr/local/bin/gtr, while the original tr is still available as
/usr/bin/tr. I have decided to go for the second option, i.e. have the GNU-versions along with the BSD-versions, but in different directories. Since their name differs, there should be no problem with
PATH either. BTW, I have not defined the variable
MANPATH either, but again this should not matter since the programs are named differently (
Now when I do a
I see the GNU tr manpage, formatted nicely; but when I just do a
I see the BSD tr manpage, with the E2-hex-sequence in it. At least this shows, under what condition it happens - the whole mess is related to the GNU utilities -, although I still don't understand, WHY it happens.