[Bug 2146344] [NEW] ls colors map to black in Linux console

[Dave Jones]

Public bug reported:

The rust version of ls has a rather unfortunate choice of color for
"backup" files. The color choice appears as dark gray on 256 color
terminals (or more) but on the Linux console (which is limited to 16
colors), it appears black -- the same as the background color, which
means backup files "disappear" from listings.

The easiest way to replicate this is to boot a resolute server image on
the bare metal (note: you must be on the Linux console itself to
replicate this, connecting from some 256-color terminal will not do it).
I'm using the Ubuntu Server daily for Raspberry Pi, but I assume (given
the Linux console is pretty standard) this *should* be reproducible on
the PC as well. Once the system has booted to the console:

$ touch foo foo.orig
$ ls
foo
$ ls -l
-rw-r--r-- 1 root root 0 Mar 25 16:02 foo
-rw-r--r-- 1 root root 0 Mar 25 16:02
$ ls --color=none
foo  foo.orig
$ ls -l --color=none
-rw-r--r-- 1 root root 0 Mar 25 16:02 foo
-rw-r--r-- 1 root root 0 Mar 25 16:02 foo.orig
$ sudo apt install gnu-coreutils
$ gnuls
foo  foo.orig

Note that the foo.orig items "disappear" with rust-coreutils ls (they're
still there, but rendered in a color that maps to the same as the
background color), but not gnu-coreutils ls. If you SSH into the box
from a system with a full color terminal, you'll see the foo.orig items
appear with a dark gray color.

Interestingly gnu-coreutils and rust-coreutils appear to pick the same
colors (at least from my regular gnome terminal client), but use
different ANSI sequences to produce them:

rust-coreutils uses \x1b[38;5;8m
gnu-coreutils uses \x1b[00;90m

The rust-coreutils code sequence is specific to 256 color terminals.
38;5 introduces a 256-color foreground change and 8 is meant to select a
dark gray color. It appears the Linux console does understand the 38;5
code but it attempts to map the chosen color to the closest match in its
16-color palette which, in this case, is black.

By contrast, the gnu-coreutils code of 90 (00 is just reset) just means
"bright black" (aka dark gray) which is one of the 16-colors in the
Linux console palette, so it just uses that.

Given that `ls=ls --color=auto` is a default on Ubuntu, and that servers
often just run the bare Linux console (with its 16-color limit), it
would probably be better to use escape sequences that don't cause files
to "disappear" (or more accurately "not show up") on the Linux console.

** Affects: rust-coreutils
     Importance: Unknown
         Status: Unknown

** Affects: rust-coreutils (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rust-coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2146344

Title:
  ls colors map to black in Linux console

Status in rust-coreutils:
  Unknown
Status in rust-coreutils package in Ubuntu:
  New

Bug description:
  The rust version of ls has a rather unfortunate choice of color for
  "backup" files. The color choice appears as dark gray on 256 color
  terminals (or more) but on the Linux console (which is limited to 16
  colors), it appears black -- the same as the background color, which
  means backup files "disappear" from listings.

  The easiest way to replicate this is to boot a resolute server image
  on the bare metal (note: you must be on the Linux console itself to
  replicate this, connecting from some 256-color terminal will not do
  it). I'm using the Ubuntu Server daily for Raspberry Pi, but I assume
  (given the Linux console is pretty standard) this *should* be
  reproducible on the PC as well. Once the system has booted to the
  console:

  $ touch foo foo.orig
  $ ls
  foo
  $ ls -l
  -rw-r--r-- 1 root root 0 Mar 25 16:02 foo
  -rw-r--r-- 1 root root 0 Mar 25 16:02
  $ ls --color=none
  foo  foo.orig
  $ ls -l --color=none
  -rw-r--r-- 1 root root 0 Mar 25 16:02 foo
  -rw-r--r-- 1 root root 0 Mar 25 16:02 foo.orig
  $ sudo apt install gnu-coreutils
  $ gnuls
  foo  foo.orig

  Note that the foo.orig items "disappear" with rust-coreutils ls
  (they're still there, but rendered in a color that maps to the same as
  the background color), but not gnu-coreutils ls. If you SSH into the
  box from a system with a full color terminal, you'll see the foo.orig
  items appear with a dark gray color.

  Interestingly gnu-coreutils and rust-coreutils appear to pick the same
  colors (at least from my regular gnome terminal client), but use
  different ANSI sequences to produce them:

  rust-coreutils uses \x1b[38;5;8m
  gnu-coreutils uses \x1b[00;90m

  The rust-coreutils code sequence is specific to 256 color terminals.
  38;5 introduces a 256-color foreground change and 8 is meant to select
  a dark gray color. It appears the Linux console does understand the
  38;5 code but it attempts to map the chosen color to the closest match
  in its 16-color palette which, in this case, is black.

  By contrast, the gnu-coreutils code of 90 (00 is just reset) just
  means "bright black" (aka dark gray) which is one of the 16-colors in
  the Linux console palette, so it just uses that.

  Given that `ls=ls --color=auto` is a default on Ubuntu, and that
  servers often just run the bare Linux console (with its 16-color
  limit), it would probably be better to use escape sequences that don't
  cause files to "disappear" (or more accurately "not show up") on the
  Linux console.

To manage notifications about this bug go to:
https://bugs.launchpad.net/rust-coreutils/+bug/2146344/+subscriptions