The Asterisk wiki says that the color of the CLI prompt can be changed with %Cn[;n]. ie:

export ASTERISK_PROMPT="%C31[%H]: "

but when I use the export above, I get broken prompt [1;31m[voip]: [1;0m, where voip is my hostname.

My terminal is color capable. In fact, I am using colors in zsh and bash. And echo $TERM gives me:


Here is a screenshot of my terminal:

enter image description here

As can be seen, even the asterisk messages/logs are colored. I have asked on the asterisk mailing list and the syntax export ASTERISK_PROMPT="%C31[%H]: " is correct. Some people reported that color prompt works for them, others had same problem as I am reporting.

This leads me to suspect, that the problem might not be in asterisk, but some complex interplay of OS environment, terminal, terminal emulator, etc.

I have tried several different terminal emulators: terminator, xterm, gnome-terminal, eterm, konsole. The problem is the same.

I use Debian 10 both on the asterisk server and my desktop from which I am connecting.

How can I get colored CLI prompt on Asterisk?


2 Answers 2


There is no local fix for this.


NetBSD editline did not support coloured prompts for years. Its mechanism that purportedly supported coloured prompts did not work, and was known to be faulty since 2015, possibly earlier. What you see is the very result of the faulty mechanism.

There is a fork of editline by Nick Zavaritsky that not only supports coloured prompts properly, it also supports (syntax) colourization of the line being edited, because it stores graphic rendition information for both the characters of the left/right prompts and the characters in the editing buffer.

Vanilla editline took a different, and arguably inferior route. In 2017 the "literal" mechanism was bodged so that literals in prompt strings actually get emitted in the right sequence, and do not break the line width calculations to boot. (It is arguably inferior because it does not support arbitrary colourization as the Zavaritsky flavour does. It preserves the original use this character to flag literal sequences mechanism of the original design, but arguably that is a poor design to aim to retain. It relies too heavily on client applications doing their own termcap lookups for colour sequences. As we shall see, that reliance is mis-placed in the case of Asterisk.)


Asterisk uses NetBSD editline, a.k.a. libedit in Debian nomenclature, not to be confused with another library that Debian calls editline.

It constructs the colourization sequences in prompts by hand, rather badly in a way that isn't really compatible with 16-colour-capable terminal emulators from the early 1990s, let alone 256-colour-capable or 24-bit-colour-capable ones. Without using termcap/terminfo to look up setaf and setab and the number of colours available, it just hardwires the escape sequences for colour, and gets them wrong, conflating bright and bold, erroneously thinking that VT100s had colour (VT100s were monochrome.), not handling more than 8 colours, and ending up emitting SGR 0 all over the place (instead of SGR 22).

Asterisk does not use the Zavaritsky flavour of editline, which (ironically) has the same problems not supporting the AIXterm 16 colours and would at least be bug-compatible in how it wrongly parses the escape sequences that Asterisk wrongly constructs. ☺

With the old vanilla flavour of editline, what you are seeing is actually the expected result. Escape sequences get printed in non-escape form. The post-2017 vanilla editline should emit them as actual escape sequences. That made it into Debian by 2018. Debian then rebuilt its Asterisk binaries in 2019.

service fix

So there is a service fix. Ensure with your package manager that you have libedit newer than 3.1-20181209 and Asterisk newer than 1:16.1.1. At least the problems will be visibly different. You won't see the effect in the question any more, but you might see problems with boldface fonts being used, bright colours not being bright, "Solarized" colour themes not fully working, and so forth.

If you still see problems with those versions, then complain to the Asterisk and NetBSD editline people; they've really only papered over the cracks, here.

  • my asterisk version is 1:16.2.1, and originally my libedit version was 3.1-20181209. I have now upgraded libedit to 3.1-20191231-1, but problem is still the same. Or did you mean, asterisk has to be recompiled with this newer libedit version? Jun 5, 2020 at 6:22
  • so I have recompiled asterisk with libedit-dev and libedit2 both on version 3.1-20191231-1. This did not solve the problem. Jun 8, 2020 at 7:50

Required library

Asterisk uses libedit for its prompt, older version of that library does not support colorisation, version newer than 3.1-20181209 is required, on Debian we can update the package with the following:

# Download the package from Debian 11
wget http://ftp.br.debian.org/debian/pool/main/libe/libedit/libedit2_3.1-20191231-1_amd64.deb
wget http://ftp.br.debian.org/debian/pool/main/libe/libedit/libedit-dev_3.1-20191231-1_amd64.deb

# Update libedit
dpkg -i libedit-dev_3.1-20191231-1_amd64.deb libedit2_3.1-20191231-1_amd64.deb

# Check the installed version
apt list --installed | grep edit

# As a side note here is the Asterisk install process:
cd /sources/dir
make clean 
make install -j8
make config
make samples

Asterisk prompt color patch:

Asterisk does have a bug with its implementation of the prompt colorisation, the following patch (for v16.2.1) introduce the usage of the env variable ASTERISK_PCOLOR that can be set to a color number, for instance export ASTERISK_PCOLOR="031" for red color; Any one is welcome to PR this patch upstream, after applying the patch make sure to use make clean before make install (as a bonus, this patch also support bold and background colorisation. example: export ASTERISK_PCOLOR="1;31;41")

--- main/asterisk.c
+++ main/asterisk.c
@@ -2548,7 +2548,7 @@
        return CLI_SUCCESS;
  * \brief Shutdown Asterisk CLI commands.
@@ -2725,6 +2725,7 @@
        char tmp[100];
        char *pfmt;
+       char *pcolor;
        int color_used = 0;
        static int cli_prompt_changes = 0;
        struct passwd *pw;
@@ -2738,6 +2739,12 @@
+       if (!(pcolor = getenv("ASTERISK_PCOLOR" ))) {
+               pcolor = "0";
+       }
+       ast_str_append(&prompt, 0, "\1\033[%sm\1", pcolor);
        if ((pfmt = getenv("ASTERISK_PROMPT"))) {
                char *t = pfmt;
                struct timeval ts = ast_tvnow();
@@ -2839,11 +2846,13 @@
                        ast_term_color_code(&prompt, 0, 0);
        } else {
-               ast_str_set(&prompt, 0, "%s%s",
+               ast_str_append(&prompt, 0, "%s%s",
                        remotehostname ? remotehostname : "",
+       ast_str_append(&prompt, 0, "\1\033[0m\1 ");
        return ast_str_buffer(prompt);
@@ -3034,7 +3043,7 @@
        el = el_init("asterisk", stdin, stdout, stderr);
-       el_set(el, EL_PROMPT, cli_prompt);
+       el_set(el, EL_PROMPT_ESC, cli_prompt, '\1');
        el_set(el, EL_EDITMODE, 1);
        el_set(el, EL_EDITOR, editor);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.