bluetoothctl terminal issues about bluez HOT 13 CLOSED

It's completely inappropriate to hardcode terminal escape sequences directly into any application instead of using a terminal capability library like ncurses to look up the correct sequences, or whether the terminal is capable of color at all.

I mostly interact with bluetoothctl with dumb terminals and the escape sequence noise has been irritating me for years

from bluez.

@Vudentz would it be possible to have an option which disable overall coloring and escape sequences (NO_COLOR or al)?
This makes scripting (expect/sexpect) unnecessarily painfull.
Thanks for consideration.

from bluez.

I suspect this has something to do with the terminal, tilix and gnome-terminal seems to work properly.

from bluez.

I also get the funny chars next to color codes. Connecting through ssh to RPI4 running Ubuntu 20. My terminal is Terminator. I've never seen this behavior with any other command neither local or remote.

bluetoothctl 5.53 shows this problem
bluetoothctl 5.48 does not

A little deeper investigation.

These are the characters it prints when starting up:
"Waiting to connect to bluetoothd...\n\x1b[22P\x1b[0;94m[bluetooth]\x1b[0m# \n\x1b[KAgent registered\n\x1b[0;94m[bluetooth]\x1b[0m# \n\x1b[K[\x01\x1b[0;93m\x02CHG\x01\x1b[0m\x02] Controller BB:BB:EB:BB:DB:BF Pairable: yes\n\x1b[0;94m[bluetooth]\x1b[0m# quit\n\x1b[0;94m[bluetooth]\x1b[0m# \n\x1b[K"

In the "[CHG]" format code there are \x01 and \x02 characters.
\x01\x1b[0;93m\x02CHG\x01\x1b[0m\x02]
--^ ------------^ -----^ ---------^
Those get funny representations in my terminal.

from bluez.

This seems to be with readline or the terminal not really supporting RL_PROMPT_START_IGNORE/RL_PROMPT_END_IGNORE: https://wiki.hackzine.org/development/misc/readline-color-prompt.html

from bluez.

You are right. After reading about it, I understand readline should be eating those characters. Do you know why would it not do so? I'm only using packages from the Ubuntu 20 repository, I think readline should be up to date then.

from bluez.

I've traced the issue down, I believe the issue is readline codes \x01 and \x02 are incorrectly being used with non-readline functions, such as vprintf. Readline functions are responsible of stripping those characters off before printing to screen. When used with vprintf the characters directly go to the screen.

shared/shell.h:15 defines COLOR_YELLOW with the offending characters
#define COLOR_YELLOW "\001\x1B[0;93m\002"
This is used in client/gatt.c:45
#define COLORED_CHG COLOR_YELLOW "CHG" COLOR_OFF
Which in turn is used in one of the many calls to bt_shell_printf such as: client/gatt.c:2156
bt_shell_printf("[" COLORED_CHG "] Attribute %s (%s) written", chrc->path, bt_uuidstr_to_str(chrc->uuid));
Then bt_shell_printf uses vprintf to directly print to terminal. shared/shell.c:542
vprintf(fmt, args);

@Vudentz

tilix and gnome-terminal seems to work properly.

Maybe your terminal is configured to not display the characters \x01 and \x02? In my machine xterm does not display them, although piping to file and inspecting shows they are indeed there.

Also: the prompt ([bluetooth]#) never gets those funny characters as it is printed through Readline.

Thank you!

from bluez.

gnome-terminal seems to work properly.

FWIW this does affect gnome-terminal under RHEL 8.

from bluez.

@Vudentz would it be possible to have an option which disable overall coloring and escape sequences (NO_COLOR or al)? This makes scripting (expect/sexpect) unnecessarily painfull. Thanks for consideration.

Yeah, or we need some means to detect if the underline terminal supports colors or not.

from bluez.

How about this:

diff --git a/src/shared/shell.h b/src/shared/shell.h
index 87fb5c415f20..a9a635bda959 100644
--- a/src/shared/shell.h
+++ b/src/shared/shell.h
@@ -10,14 +10,14 @@
 #include <getopt.h>
 #include <stdbool.h>
 
-#define COLOR_OFF      "\001\x1B[0m\002"
-#define COLOR_RED      "\001\x1B[0;91m\002"
-#define COLOR_GREEN    "\001\x1B[0;92m\002"
-#define COLOR_YELLOW   "\001\x1B[0;93m\002"
-#define COLOR_BLUE     "\001\x1B[0;94m\002"
-#define COLOR_BOLDGRAY "\001\x1B[1;30m\002"
-#define COLOR_BOLDWHITE        "\001\x1B[1;37m\002"
-#define COLOR_HIGHLIGHT        "\001\x1B[1;39m\002"
+#define COLOR_OFF      "\x1B[0m"
+#define COLOR_RED      "\x1B[0;91m"
+#define COLOR_GREEN    "\x1B[0;92m"
+#define COLOR_YELLOW   "\x1B[0;93m"
+#define COLOR_BLUE     "\x1B[0;94m"
+#define COLOR_BOLDGRAY "\x1B[1;30m"
+#define COLOR_BOLDWHITE        "\x1B[1;37m"
+#define COLOR_HIGHLIGHT        "\x1B[1;39m"

from bluez.

Again, I have to ask, do you not understand what ncurses/terminfo is for? Terminal capabilities are only 40-year old technology.

from bluez.

Again, I have to ask, do you not understand what ncurses/terminfo is for? Terminal capabilities are only 40-year old technology.

We won't be rewriting bluetoothctl using ncurses anytime soon, we are using libreadline which doesn't seem to handle the use of colors that well (https://wiki.hackzine.org/development/misc/readline-color-prompt.html), or if you have a better idea please enlight us.

Btw, I get that you may be frustated that this issue has been known for a while, but I don't think you are really helping by stating it is a 40-year old technology, etc, specially because it makes no difference if readline can't really calculate the prompt length properly without the use of escape sequences when colors are used.

from bluez.

How about this:

Could not test it yet, sorry.
However, wouldn't it be possible to simply filter-out all those color codes if a certain parameter is passed or env variable set (like NO_COLOR)?

from bluez.