Hacker News Reader

Comment by jf | Hacker News Reader

The tl;dr here is that "ls" can be much faster if you disable colorizing files based on the their file capabilities, setuid/setgid bits, or executable flag.

    LS_COLORS='ex=00:su=00:sg=00:ca=00:'

View on HN

Does that leave any colorizing? I guess dirent still has d_type information, which should allow coloring based on type (directory, block device, symlink, socket, etc). (This information is also contained in stat's st_mode.)

Yes, it leaves all of the default coloring, except for the bits that require additional syscalls, that is: executable permission, setuid/setgid bits, and file capabilities.

And if you don't want angry fruit salad colors in your cool hipster retro-Matrix semitransparent tiling-window desktop theme:

  unset LS_COLORS
  alias l='/bin/ls -a'
  alias ll='/bin/ls -alF'

I’d argue that for the vast majority of manual usages of ls, the maybe second or so saved listing directory contents by removing colors will be dwarfed by the additional time it takes the human to parse its contents, without the additional context provided by those colors.

I'd agree with you: judicious and consistent use of color should give better HCI performance than the colorless method, for the majority of people.

But it's very visual and aesthetic, and maybe it's best considered a user preference, which is why the tongue-in-cheek rationale, when I mentioned the option.

Good points. And for those wondering, "HCI" means Human Computer Interaction (had to check).

Thanks. HCI (and human factors engineering) were the original areas of study concerned with these questions. UX, which is more popular at the moment, seems to have more emphasis on visual appeal and marketing psychology, rather than on effectiveness for the user's goals. You could see "dark patterns" as an extreme of this shift in intent.

> unset LS_COLORS

Quoting from the article, "It turns out that when the LS_COLORS environment variable is not defined, or when just one of its <type>=color: elements is not there, it defaults to its embedded database and uses colors anyway."

From looking at a version of the likely C source (`coreutils` source, as packaged by Debian), it looks like they're aggressively trying to use color. In addition to `LS_COLORS`, they also look at `COLORTERM`. There's also C variables to chase through the source; `print_with_color` seems most likely one to focus on.

In addition to that code, the shell init scripts (both system-wide, and user-specific default ones that are copied in) might do things like checking whether a variable is set, and setting it, if not (or simply overriding, regardless).

Literally undoing the improvement to make it non-colorful?

Reply on news.ycombinator.com