Supported Colors

Unfortunately, interpretation of colors 0 through 7 often depends on whether the emulator supports eight colors or sixteen colors. Emulators that only support eight colors (such as the Linux console) will display colors 0 through 7 with normal brightness and ignore colors 8 through 15, treating them the same as white. Emulators that support 16 colors, such as gnome-terminal, normally display colors 0 through 7 as dim or darker versions and colors 8 through 15 as normal brightness. On such emulators, the "normal" white (color 7) usually is shown as pale grey, requiring bright white (15) to be used to get a real white color. Bright black usually is a dark grey color, although some terminals display it as pure black. Some sixteen-color terminal emulators also treat normal yellow (color 3) as orange or brown, and bright yellow (color 11) as yellow.

Following the normal convention of sixteen-color emulators, this module provides a pair of attributes for each color. For every normal color (0 through 7), the corresponding bright color (8 through 15) is obtained by prepending the string "bright_" to the normal color name. For example, "red" is color 1 and "bright_red" is color 9. The same applies for background colors: "on_red" is the normal color and "on_bright_red" is the bright color. Capitalize these strings for the constant interface.

There is unfortunately no way to know whether the current emulator supports more than eight colors, which makes the choice of colors difficult. The most conservative choice is to use only the regular colors, which are at least displayed on all emulators. However, they will appear dark in sixteen-color terminal emulators, including most common emulators in UNIX X environments. If you know the display is one of those emulators, you may wish to use the bright variants instead. Even better, offer the user a way to configure the colors for a given application to fit their terminal emulator.

For 256-color emulators, this module additionally provides "ansi0" through "ansi15", which are the same as colors 0 through 15 in sixteen-color emulators but use the 256-color escape syntax, "grey0" through "grey23" ranging from nearly black to nearly white, and a set of RGB colors. The RGB colors are of the form "rgbRGB" where R, G, and B are numbers from 0 to 5 giving the intensity of red, green, and blue. The grey and RGB colors are also available as "ansi16" through "ansi255" if you want simple names for all 256 colors. "on_" variants of all of these colors are also provided. These colors may be ignored completely on non-256-color terminals or may be misinterpreted and produce random behavior. Additional attributes such as blink, italic, or bold may not work with the 256-color palette.

For true color emulators, this module supports attributes of the form "rNNNgNNNbNNN" and "on_rNNNgNNNbNNN" for all values of NNN between 0 and 255. These represent foreground and background colors, respectively, with the RGB values given by the NNN numbers. These colors may be ignored completely on non-true-color terminals or may be misinterpreted and produce random behavior.

Function Interface

Note that not all attributes are supported by all terminal types, and some terminals may not support any of these sequences. Dark and faint, italic, blink, and concealed in particular are frequently not implemented.

The recognized normal foreground color attributes (colors 0 to 7) are:

  black  red  green  yellow  blue  magenta  cyan  white

The corresponding bright foreground color attributes (colors 8 to 15) are:

  bright_black  bright_red      bright_green  bright_yellow
  bright_blue   bright_magenta  bright_cyan   bright_white

The recognized normal background color attributes (colors 0 to 7) are:

  on_black  on_red      on_green  on yellow
  on_blue   on_magenta  on_cyan   on_white

The recognized bright background color attributes (colors 8 to 15) are:

  on_bright_black  on_bright_red      on_bright_green  on_bright_yellow
  on_bright_blue   on_bright_magenta  on_bright_cyan   on_bright_white

For 256-color terminals, the recognized foreground colors are:

  ansi0 .. ansi255
  grey0 .. grey23

plus "rgbRGB" for R, G, and B values from 0 to 5, such as "rgb000" or "rgb515". Similarly, the recognized background colors are:

  on_ansi0 .. on_ansi255
  on_grey0 .. on_grey23

plus "on_rgbRGB" for R, G, and B values from 0 to 5.

For true color terminals, the recognized foreground colors are "rRRRgGGGbBBB" for RRR, GGG, and BBB values between 0 and 255. Similarly, the recognized background colors are "on_r RRRgGGG bBBB" for RRR, GGG, and BBB values between 0 and 255.

For any of the above listed attributes, case is not significant.

Attributes, once set, last until they are unset (by printing the attribute "clear" or "reset"). Be careful to do this, or otherwise your attribute will last after your script is done running, and people get very annoyed at having their prompt and typing changed to weird colors.

color(ATTR[, ATTR ...])

color() takes any number of strings as arguments and considers them to be space-separated lists of attributes. It then forms and returns the escape sequence to set those attributes. It doesn't print it out, just returns it, so you'll have to print it yourself if you want to. This is so that you can save it as a string, pass it to something else, send it to a file handle, or do anything else with it that you might care to. color() throws an exception if given an invalid attribute.

colored(STRING, ATTR[, ATTR ...])

colored(ATTR-REF, STRING[, STRING...])

As an aid in resetting colors, colored() takes a scalar as the first argument and any number of attribute strings as the second argument and returns the scalar wrapped in escape codes so that the attributes will be set as requested before the string and reset to normal after the string. Alternately, you can pass a reference to an array as the first argument, and then the contents of that array will be taken as attributes and color codes and the remainder of the arguments as text to colorize.

Normally, colored() just puts attribute codes at the beginning and end of the string, but if you set $Term::ANSIColor::EACHLINE to some string, that string will be considered the line delimiter and the attribute will be set at the beginning of each line of the passed string and reset at the end of each line. This is often desirable if the output contains newlines and you're using background colors, since a background color that persists across a newline is often interpreted by the terminal as providing the default background color for the next line. Programs like pagers can also be confused by attributes that span lines. Normally you'll want to set $Term::ANSIColor::EACHLINE to "\n" to use this feature.

Particularly consider setting $Term::ANSIColor::EACHLINE if you are interleaving output to standard output and standard error and you aren't flushing standard output (via autoflush() or setting $|). If you don't, the code to reset the color may unexpectedly sit in the standard output buffer rather than going to the display, causing standard error output to appear in the wrong color.

uncolor(ESCAPE)

uncolor() performs the opposite translation as color(), turning escape sequences into a list of strings corresponding to the attributes being set by those sequences. uncolor() will never return "ansi16" through "ansi255", instead preferring the "grey" and "rgb" names (and likewise for "on_ansi16" through "on_ansi255").

colorstrip(STRING[, STRING ...])

colorstrip() removes all color escape sequences from the provided strings, returning the modified strings separately in array context or joined together in scalar context. Its arguments are not modified.

colorvalid(ATTR[, ATTR ...])

colorvalid() takes attribute strings the same as color() and returns true if all attributes are known and false otherwise.

coloralias(ALIAS[, ATTR ...])

If ATTR is specified, it is interpreted as a list of space-separated strings naming attributes or existing aliases. In this case, coloralias() sets up an alias of ALIAS for the set of attributes given by ATTR. From that point forward, ALIAS can be passed into color(), colored(), and colorvalid() and will have the same meaning as the sequence of attributes given in ATTR. One possible use of this facility is to give more meaningful names to the 256-color RGB colors. Only ASCII alphanumerics, ".", "_", and "-" are allowed in alias names.

If ATTR includes aliases, those aliases will be expanded at definition time and their values will be used to define the new alias. This means that if you define an alias A in terms of another alias B, and then later redefine alias B, the value of alias A will not change.

If ATTR is not specified, coloralias() returns the standard attribute or attributes to which ALIAS is aliased, if any, or undef if ALIAS does not exist. If it is aliased to multiple attributes, the return value will be a single string and the attributes will be separated by spaces.

This is the same facility used by the ANSI_COLORS_ALIASES environment variable (see "ENVIRONMENT" below) but can be used at runtime, not just when the module is loaded.

Later invocations of coloralias() with the same ALIAS will override earlier aliases. There is no way to remove an alias.

Aliases have no effect on the return value of uncolor().

WARNING: Aliases are global and affect all callers in the same process. There is no way to set an alias limited to a particular block of code or a particular object.

Constant Interface

  CLEAR           RESET             BOLD            DARK
  FAINT           ITALIC            UNDERLINE       UNDERSCORE
  BLINK           REVERSE           CONCEALED

  BLACK           RED               GREEN           YELLOW
  BLUE            MAGENTA           CYAN            WHITE
  BRIGHT_BLACK    BRIGHT_RED        BRIGHT_GREEN    BRIGHT_YELLOW
  BRIGHT_BLUE     BRIGHT_MAGENTA    BRIGHT_CYAN     BRIGHT_WHITE

  ON_BLACK        ON_RED            ON_GREEN        ON_YELLOW
  ON_BLUE         ON_MAGENTA        ON_CYAN         ON_WHITE
  ON_BRIGHT_BLACK ON_BRIGHT_RED     ON_BRIGHT_GREEN ON_BRIGHT_YELLOW
  ON_BRIGHT_BLUE  ON_BRIGHT_MAGENTA ON_BRIGHT_CYAN  ON_BRIGHT_WHITE

These are the same as color('attribute') and can be used if you prefer typing:

    print BOLD BLUE ON_WHITE "Text", RESET, "\n";

to

    print colored ("Text", 'bold blue on_white'), "\n";

(Note that the newline is kept separate to avoid confusing the terminal as described above since a background color is being used.)

If you import ":constants256", you can use the following constants directly:

  ANSI0 .. ANSI255
  GREY0 .. GREY23

  RGBXYZ (for X, Y, and Z values from 0 to 5, like RGB000 or RGB515)

  ON_ANSI0 .. ON_ANSI255
  ON_GREY0 .. ON_GREY23

  ON_RGBXYZ (for X, Y, and Z values from 0 to 5)

Note that ":constants256" does not include the other constants, so if you want to mix both, you need to include ":constants" as well. You may want to explicitly import at least "RESET", as in:

    use Term::ANSIColor 4.00 qw(RESET :constants256);

True color and aliases are not supported by the constant interface.

When using the constants, if you don't want to have to remember to add the ", RESET" at the end of each print line, you can set $Term::ANSIColor::AUTORESET to a true value. Then, the display mode will automatically be reset if there is no comma after the constant. In other words, with that variable set:

    print BOLD BLUE "Text\n";

will reset the display mode afterward, whereas:

    print BOLD, BLUE, "Text\n";

will not. If you are using background colors, you will probably want to either use say() (in newer versions of Perl) or print the newline with a separate print statement to avoid confusing the terminal.

If $Term::ANSIColor::AUTOLOCAL is set (see below), it takes precedence over $Term::ANSIColor::AUTORESET, and the latter is ignored.

The subroutine interface has the advantage over the constants interface in that only two subroutines are exported into your namespace, versus thirty-eight in the constants interface, and aliases and true color attributes are supported. On the flip side, the constants interface has the advantage of better compile time error checking, since misspelled names of colors or attributes in calls to color() and colored() won't be caught until runtime whereas misspelled names of constants will be caught at compile time. So, pollute your namespace with almost two dozen subroutines that you may not even use that often, or risk a silly bug by mistyping an attribute. Your choice, TMTOWTDI after all.

The Color Stack

If $Term::ANSIColor::AUTOLOCAL is set, each sequence of color constants will be implicitly preceded by LOCALCOLOR. In other words, the following:

    {
        local $Term::ANSIColor::AUTOLOCAL = 1;
        print BLUE "Text\n";
    }

is equivalent to:

    print LOCALCOLOR BLUE "Text\n";

If $Term::ANSIColor::AUTOLOCAL is set, it takes precedence over $Term::ANSIColor::AUTORESET, and the latter is ignored.

When using PUSHCOLOR, POPCOLOR, and LOCALCOLOR, it's particularly important to not put commas between the constants.

    print PUSHCOLOR BLUE "Text\n";

will correctly push BLUE onto the top of the stack.

    print PUSHCOLOR, BLUE, "Text\n";    # wrong!

will not, and a subsequent pop won't restore the correct attributes. PUSHCOLOR pushes the attributes set by its argument, which is normally a string of color constants. It can't ask the terminal what the current attributes are.

Supporting CLICOLOR

    if (exists($ENV{CLICOLOR}) && $ENV{CLICOLOR} == 0) {
        if (!$ENV{CLICOLOR_FORCE}) {
            $ENV{ANSI_COLORS_DISABLED} = 1;
        }
    }

If you are using the constant interface, be sure to include this code before you use any color constants (such as at the very top of your script), since this environment variable is only honored the first time a color constant is seen.

Be aware that this will export ANSI_COLORS_DISABLED to any child processes of your program as well.