Invalid LS_COLORS in node profile causes ls warnings when color is enabled

[Vonng]

Summary

roles/node/files/node.sh exports a malformed LS_COLORS entry:

:or=40;31;01:\ex=01;32:

The executable-file indicator must be ex=01;32 without the leading backslash. When GNU ls color output is enabled, interactive commands emit:

ls: unparsable value for LS_COLORS environment variable

The listing still succeeds with exit status 0, but color output is disabled and stderr is polluted.

Why this became visible now

The malformed value has existed since the node profile first entered the current Git history in commit a6f7708c (2020-10-22).

Commit af28c6be (included in v4.4.0 and v4.5.0) changed the color capability probe from:

[ ls --color ] >/dev/null 2>&1 && colorflag="--color" || colorflag="-G"

to:

command ls --color >/dev/null 2>&1 && colorflag="--color" || colorflag="-G"

The old expression invoked the shell [/test builtin instead of ls, failed, and selected -G. On GNU ls, -G means --no-group, not color, so the invalid environment variable remained latent. The corrected probe now selects --color, causing ls to parse and reject the old typo.

Reproduction

export LS_COLORS='di=01;34:\ex=01;32'
ls --color=always -d /tmp

Affected platforms

The same failure was reproduced with:

• Rocky Linux 8 / GNU coreutils 8.30
• Rocky Linux 9 / GNU coreutils 8.32
• Rocky Linux 10 / GNU coreutils 9.5
• Debian 12 / GNU coreutils 9.1
• Debian 13 / GNU coreutils 9.7
• Ubuntu 22.04 / GNU coreutils 8.32
• Ubuntu 24.04 / GNU coreutils 9.4
• Ubuntu 26.04 / uutils coreutils 0.8.0

GNU coreutils 8.25 also rejects the value, so this is not specific to EL10 or a recent shell/coreutils change. macOS BSD ls and Alpine BusyBox ignore LS_COLORS and do not emit this warning.

Proposed fix

Replace the invalid indicator with the standard two-character key:

-:or=40;31;01:\ex=01;32:
+:or=40;31;01:ex=01;32:

Validate the corrected value by invoking color-enabled ls across the supported Linux matrix.