# Enabling ANSI escape color code will result in unexpected results

**URL:** https://discourse.cmake.org/t/enabling-ansi-escape-color-code-will-result-in-unexpected-results/9780
**Category:** Usage
**Created:** [January 5, 2024, 6:29pm UTC](https://discourse.cmake.org/t/enabling-ansi-escape-color-code-will-result-in-unexpected-results/9780 "2024-01-05T18:29:47Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![cristianadam](https://discourse.cmake.org/user_avatar/discourse.cmake.org/cristianadam/32/124_2.png) [@cristianadam](https://discourse.cmake.org/u/cristianadam)
#### Post date: [January 5, 2024, 6:29pm UTC](https://discourse.cmake.org/t/enabling-ansi-escape-color-code-will-result-in-unexpected-results/9780/1 "2024-01-05T18:29:47Z")

</div>

At [[QTCREATORBUG-30147] ERROR\_VARIABLE from execute\_process is not working as expected - Qt Bug Tracker](https://bugreports.qt.io/browse/QTCREATORBUG-30147) we can see the following code:

```cmake
cmake_minimum_required(VERSION 3.14)
project(QtCreatoCmakeBug)

unset(generated_files)
execute_process(COMMAND ${CMAKE_COMMAND}
           -P ${CMAKE_CURRENT_SOURCE_DIR}/myScript.cmake
           ERROR_VARIABLE error_output) # CMake writes messages to standard error.

string(STRIP "${error_output}" error_output)
list(LENGTH error_output error_output_len)
message("error_output list ${error_output} length: ${error_output_len}")

# Same list variable
set(my_file_list "myFile1.h;myFile1.cpp")
list(LENGTH my_file_list my_file_list_len)
message("my_file_list list ${my_file_list} length: ${my_file_list_len}")

```

with `myScript.cmake` as:

```cmake
cmake_minimum_required(VERSION 3.16)
message("myFile1.h;myFile1.cpp")

```

The `length` is reported as 2 and 2 with Qt Creator 11, and 1 and 2 for Qt Creator 12.

This is due to the fact that Qt Creator 12 sets `CLICOLOR_FORCE` to `1` which causes the CMake run via `execute_process` to inject escape codes.

The output is actually:

```auto
e[0mmyFile1.h;myFile1.cppe[0m

```

The fix would be either use:

```cmake
string(ASCII 27 Esc)
string(REPLACE "${Esc}[0m" "" error_output "${error_output}")

```

or set `CLICOLOR_FORCE` to `0` for the CMake project in Qt Creator.

But what about fixing this at CMake level? I can think of two fixes:

1. `string(STRIP "${error_output}" error_output)` would also strip the escape codes
2. `list(LENGTH error_output error_output_len)` would ignore the escape codes
3. Ignore issue and fix it via _documentation_

Any thoughts?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [January 11, 2024, 1:33pm UTC](https://discourse.cmake.org/t/enabling-ansi-escape-color-code-will-result-in-unexpected-results/9780/2 "2024-01-11T13:33:32Z")

</div>

> [@cristianadam](#):
>
> - `string(STRIP "${error_output}" error_output)` would also strip the escape codes
> - `list(LENGTH error_output error_output_len)` would ignore the escape codes

Either of these would need to be a policy change. I don’t think we could reliably do that without changing behavior silently. A `string(STRIP_ANSI)` command sounds fine though.

I think the issue is that using `CLICOLOR_FORCE=1` is the wrong thing to do as not everything is expecting this. Better would be if we had something like `cmake --color=<auto|on|off>` Including, ironically, Qt Creator choking on my `NINJA_STATUS` with oodles of color settings when I last tried it (years ago).

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [January 12, 2024, 8:35am UTC](https://discourse.cmake.org/t/enabling-ansi-escape-color-code-will-result-in-unexpected-results/9780/3 "2024-01-12T08:35:33Z")

</div>

If your `execute_process()` call might change its output depending on whether certain environment variables are set, and your project is sensitive to those changes, then the project should be ensuring those environment variables are controlled as part of the call. In other words, explicitly set `CLICOLOR_FORCE=0` as part of the command. There could be a range of environment variables that might matter to a project, `CLICOLOR_FORCE` is just one example. I don’t think CMake should manage these with dedicated options, there are already fairly straightforward ways for a project to do this without them.