| |||||||||||||
Colour lsColour lsPosted Dec 2, 2004 3:48 UTC (Thu) by ewen (subscriber, #4772)Parent article: Debian and the hot babe problem
IMHO the biggest problem with colour ls is not the notion of having ls output coloured (which is sometimes useful), but the fact that the default colour schemes (at least as used by various distributions) are seemingly optimised for minimal readability (dark blue on black, there's a good combination! Not.) and/or maximum garishness (often both at the same time).
I have much the same view on colour syntax highlighting in editors. Done properly it can be quite useful. But the defaults generally show the feature in its worst light (unreadable colour combinations, a different colour for every word, etc).
My solution to both is to have a minimal set of useful colours which I carry from machine to machine, installing them each time the defaults bother me. (My .vimrc uses only four colours for virtually everything and is quite usable, unlike the common defaults. I have a few more ls colours, but they're only used for obscure things.)
Perhaps the distributions could give some thought to more useful sets of colours. (I notice more recent RedHat Enterprise Server versions at least have two sets of colours for dark-background and light-background situations. It's unfortunate that it's detection of which to use doesn't work as well as might be desired -- _my_ xterms have black backgrounds.)
Ewen
(Log in to post comments)
Colour ls Posted Dec 2, 2004 15:16 UTC (Thu) by kael (subscriber, #1599) [Link] I actually went to the trouble of turning on comments to make just this point.
There is nothing wrong with color ls. The defaults are bad (BAD), but a couple of minutes reveals how to customize (and improve) the settings and then spread as you will.
One could lump vim in the same basket, same solution applies (I admit to liking the blue color scheme, harking back to the DOS 5.0 edit days).
if ( baby and water ) {
Colour ls Posted Jan 1, 2005 23:22 UTC (Sat) by Ross (subscriber, #4065) [Link] If only the configuration file let you use RGB triplets for specifyingthe colors. Instead it takes a raw chunks of extended VT100/ANSI terminal control sequences. Unfortunately not the entire sequence... just a portion from the middle. Thus you can only use the basic foreground and background colors which are quite ugly. The only way to obtain less saturated, less clashing, and brighter colors is to change your XTerm color settings so that they no longer match with the specified colors.
If they had been more flexible you could use the builtin color cube for the
So I agree that in theory color directory listing could be ok, the
Colour ls Posted Dec 2, 2004 16:45 UTC (Thu) by nix (subscriber, #2304) [Link] dark blue on black, there's a good combination! Not.It's fine for backup files and other totally nonimportant files. (Assuming your background colour is black, of course.) I whipped up a script some time back which you tell your terminal background colour and it ensures that your colour-ls and grep colourization settings don't clash with some horrid seddery. (This is necessary when installing software for use in a work environment where some people colour their xterms like fruit salad. Bright red backgrounds and green and orange text, I ask you...)
Colour ls Posted Dec 2, 2004 21:25 UTC (Thu) by ewen (subscriber, #4772) [Link] dark blue on black, there's a good combination! Not.It's fine for backup files and other totally nonimportant files. (Assuming your background colour is black, of course.) The problem, of course, is that at least with my terminal setup (off-white on black), these "dark blue on black" combinations turn up, with most vendors defaults, for directory names. Which don't quite count as "totally nonimportant"... While you're perhaps right that it could be used for something unimportant, I prefer simply not to colour the things I don't care about and they become "and other stuff". My main point, however, was that the defaults were fairly terrible, which everyone seems to agree with. I too have various shell, sed, etc magic, to make for better defaults and deal with black-background and white-background better. But it shouldn't be necessary to fix every system I use; the vendor defaults should be better, and at least default to "reasonably useable on most setups". Ewen
Colour ls Posted Dec 2, 2004 17:17 UTC (Thu) by jabby (guest, #2648) [Link] I actually *like* color ls.
I use a white background, so I don't have as much trouble with the dark colors. The bold light blue default for soft links is hard to read, but I usually want to know what it points to if I care about it and in a long listing (-l) the target is shown with its own appropriate (more legible) color assignment.
Color ls is also good for recognizing the *lack* of color. Since the color is based not only on file type (directory, soft link, socket, etc.), but also on permissions (executable) and extension, one can quickly glean information about the types of files in a directory. And if one is expecting a certain type of file to be present, it's absence is immediately noticed. It's especially useful in my src directories. I can immediately see whether a directory has been built or needs to be cleaned, etc.
I've also gone to the (mild) trouble of customizing the color output to highlight our in-house extensions (.980, .909, etc.) and to subtly indicate the difference between .o binaries (light green) and executable binaries (light green & bold!).
I think it's pretty widely accepted that using color (and other visual cues, such as bold or italics) is a great way of organizing and grouping sets of data. The mind instantly recognizes objects of the same color as a "set" of a sort. And if they happen to appear as a block, they *really* jump out at you. The more your brain can process visually, the less brain cycles you need to spend figuring it out by reading the text and processing its meaning.
Jason
Colour ls Posted Dec 2, 2004 18:54 UTC (Thu) by iabervon (subscriber, #722) [Link] An alternative (which I do) is to make your colors contrast better with a dark background:
XTerm*background: MidnightBlue
(xterm does the "bright" colors with bold, which is sufficiently visible for me for 9 and 13 but not 12)
I have a little cat script to use ANSI escape sequences to display all the colors, bright and normal, when is good for tuning this (but it's a bit tricky to post, being full of ESC characters).
Colour ls Posted Dec 4, 2004 8:59 UTC (Sat) by astrand (guest, #4908) [Link] A solution that seems to work on RedHat/Fedora systems is "eval `dircolors`".
|
|||||||||||||