Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

strange output characters from perldoc

by dbae (Beadle)
on Apr 30, 2012 at 09:34 UTC ( #968030=perlquestion: print w/replies, xml ) Need Help??
dbae has asked for the wisdom of the Perl Monks concerning the following question:

When I use perldoc, I get many characters like this ESC[1m with many variants. This happens, for example, when I type
perldoc perldoc
to the Unix command line, making the output unreadable. I checked the output of perldoc perldoc by piping in Unix to a hexdump program, and it really is outputting Escape [ 1 m.

Could someone please tell me the name of this type of encoding, so I could check out what perldoc is trying to say to me?

I run MacOsX 10.6.8 and my version of perl is downloaded from Macports. perl --version gives:
perl 5, version 12, subversion 3 (v5.12.3) built for darwin-multi-2level.
Can I fix my perldoc problem a) in MacOsX b) in perl?

Is this a MacOsX problem or a perldoc problem?

Replies are listed 'Best First'.
Re: strange output characters from perldoc
by MidLifeXis (Monsignor) on Apr 30, 2012 at 13:08 UTC

    Try an echo $TERM at the same console, and see what pops out. My guess is that it is set to something that understands escape sequences (for bold, underline, colors, etc), but your terminal is not configured to understand those sequences.

    By default (IIRC), unless your system is Windows, perl tries to use pod2man to format its output. The nroff program is then used to format the output as necessary to display on the type of terminal identified in the $TERM environment variable. If the variable and your current terminal capabilities do not match, you can see the output you are describing. Does man cat also display those escape sequences?


Re: strange output characters from perldoc
by roboticus (Chancellor) on Apr 30, 2012 at 13:33 UTC


    The previous posters are correct. Having said that, you might look at your shell initialization script: I'm guessing that it's setting your TERM variable to something incompatible with your command console. Many *nix programs will read the TERM variable to determine what features it can use to format your output better. However, if it's set to something incompatible with your terminal program, you'll get exactly the situation you describe. Be sure to check that your terminal software has enough features, too. If you want color, boldface, underlines, etc., be sure you use a program that handles it.

    The documentation for your terminal software should tell you enough information to figure out what the correct TERM value should be. (Though it may be overly cryptic, or not stated directly enough.) For example, the terminal I'm using here at work is mintty, and in the documentation it mentions:

    Terminal emulation settings.

    Type (Term=xterm)

    The terminal type. This determines the setting of the TERM environment variable at mintty startup. Choices available from the dropdown list are xterm, xterm-256color, xterm-vt220, vt220, and vt100.

    If the setting contains "vt220", xterm VT220-style function key mode is enabled instead of the default PC-style function key mode. (This can otherwise be set with the DECSET 1061 control sequence.)

    Apart from that, this setting has no effect on mintty's terminal emulation, i.e. all the features are always available. However, the TERM setting does tell applications what features they can use.

    The xterm-256color setting enables 256-color mode in some applications, but may not be recognised at all by others, which is why plain xterm is the default.

    So on my setup, I'm using TERM=xterm (I would have added it to my .bashrc script, except that mintty defaults to setting the value for me.)


    When your only tool is a hammer, all problems look like your thumb.

      echo $TERM gave me xterm-color, so I set it to xterm, but no change to output from perldoc perldoc resulted. I'm stuck between not knowing enough *n*x and not knowing enough MacOsX. MacOsX has an entirely non-*n*x way of setting properties of the terminal emulator given by the MacOsX program Terminal, but one can also affect things in the usual *n*x way. I haven't been able to find anything in MacOsX saying "set the properties of the terminal emulator to vt220", or anything similar. However, I don't have the time to go into it all, so I'm just going to leave matters in their current unsatisfactory state. At least, using the advice given here, I now have several ways of reading the output from perldoc, and also, and this has improved my relationship with perl. Thanks to everyone for this.

        Perhaps OS X Terminal Emulation Woes might be handy? If not, you might look to see if you can download a copy of RXVT or similar.


        When your only tool is a hammer, all problems look like your thumb.

      Hi :) this means text

      $ echo %os% Windows_NT $ echo %term% dumb
Re: strange output characters from perldoc
by Anonymous Monk on Apr 30, 2012 at 09:43 UTC
      -o text works well. Thanks
Re: strange output characters from perldoc
by Anonymous Monk on Apr 30, 2012 at 11:27 UTC
    These are ANSI escape codes. Your terminal should interpret them to make text appear bold, underlined, etc.
Re: strange output characters from perldoc
by erix (Parson) on Apr 30, 2012 at 16:33 UTC

    FWIW, I like:

    perldoc -tT perldoc | gvim - # or whatever reader/file
Re: strange output characters from perldoc
by kcott (Chancellor) on May 01, 2012 at 03:45 UTC

    G'day dbae,

    I have the same problem using Mac OS X 10.7.3 and Perl 5.14.2 with the Mac application Terminal. I've used a number of different OSes over the years and haven't seen this issue previously: this suggests a Mac OS X problem; although, it could be related to just the perldoc implementation on Mac OS X.

    I use ANSI escape codes in $PS1 and $PS2 and these seem to work perfectly. From my .bash_profile:

    PS1='\[\033[0;36m\]\u@\h: \w\n\$ \[\033[0m\]' PS2='\[\033[0;36m\]> \[\033[0m\]'

    While fixing this is on my TODO list, it has a fairly low priority as I tend to use in preference to the commandline perldoc. Looking for a quick fix some months ago, I investigated $TERM values (suggested above) as well as $LANG and $LC_* (locale) values. I didn't find a solution in whatever timeframe I allotted but these are areas I would be researching further in the future: perhaps that's of some use to you.

    -- Ken

      Try looking at your PAGER environment variable. Mine was set to "more" and it was messing up from the output from perldoc (although normal "man" worked fine). I switched PAGER to be "less -R" and now perldoc looks good.

      This is using xterm on FreeBSD, FWIW.

        ++ Thanks! I had less; less -R is a vast improvement.

        -- Ken

        Perfect. This solved my problem too! My term was xterm-256color and man worked fine, although perldoc had escape sequences just like described here. setting my PAGER to less -R solved it for me!!! Thank you!!

      although, it could be related to just the perldoc implementation on Mac OS X.

      No, no it couldn't, see for yourself

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://968030]
Approved by davido
Front-paged by Arunbear
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2018-01-22 00:39 GMT
Find Nodes?
    Voting Booth?
    How did you see in the new year?

    Results (230 votes). Check out past polls.