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

[Dave Jones]

Argh, something I hadn't noticed which almost certainly makes this
invalid: I was running under tmux (something I more or less run without
thinking on the bare console), and this is setting $TERM to
"tmux-256color" (erroneously given the linux console definitely doesn't
support 256 colors). Under this environment, the issue occurs, but under
the bare Linux console (without tmux where $TERM is simply "linux"), it
does not. The escape sequence produced is no different, but the bare
Linux console does indeed output dark-gray / bright-black for the
sequence.

I've closed the upstream bug but I'm in two minds what to do down here
in the distro. Do I regard this as an issue in tmux and re-assign it to
that?

It does seem there's something iffy about its ANSI sequence
interpretation. Further, tmux is seeded by default on server images, and
is a common choice now that byobu is no longer present, so I can see
people running into this and getting as confused as I initially was.

On the other hand, it's not necessarily an incorrect treatment of this
ANSI escape sequence ...

I need to do some more reading before I make up my mind, but I'll mark
this invalid for rust-coreutils in the meantime.

** Changed in: rust-coreutils (Ubuntu)
       Status: New => Invalid

-- 
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:
  New
Status in rust-coreutils package in Ubuntu:
  Invalid

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