'Linux'... First Introduction !!

[rstofer]

Here is LS_COLORS, ready to modify

Code: [Select]


LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41
:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31
:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31
:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31
:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31
:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35
:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35
:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35
:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35
:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35
:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36
:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36
:*.spx=00;36:*.xspf=00;36:


This version is the default on Raspian and is all one line.  I added some line breaks above.

Just a tweak here and there and we're all set!

[Nominal Animal]

This version is the default on Raspian and is all one line.  I added some line breaks above.

Yep! The Ubuntu 18.04 LTS version is almost the same, just adds one for .Z suffixed files as well, :*.Z=01;31: .

If e-ink -type reflective type displays get more colors and become fast enough for terminal use, I'll definitely switch from black background to a white one, and change the coloring.  I've done some experiments with the colors, and could not find significant improvements in the 16-color set for use on a black background.  Changing the exact color values in the terminal emulator itself to yield easily read but still distinguishing variants of those respective colors makes much more a difference; in particular, making the two blue colors brighter, so that even normal (dark) blue is legible.

For gnome-terminal, I use a custom scheme with lighter dark blue etc., because I keep the brightness of my monitors very low for comfort.

For text/source editing, I use Pluma, with a custom theme (with a pure black background) based on Oblivion theme.

It's because, even though I know the ls colors can be changed, every time I set up a system, I have to go research the fix once again.  I won't remember it because it is a one-and-done deal until it comes up yet again.  How about some code in .bashrc to make the change easy?

You know, it is there.  If you create the .dircolors file in your home directory, containing dircolors -p output with your own customizations, say

Code: [Select]

# Configuration file for dircolors, a utility to help you set the
# LS_COLORS environment variable used by GNU ls with the --color option.
# Copyright (C) 1996-2017 Free Software Foundation, Inc.
# Copying and distribution of this file, with or without modification,
# are permitted provided the copyright notice and this notice are preserved.
# The keywords COLOR, OPTIONS, and EIGHTBIT (honored by the
# slackware version of dircolors) are recognized but ignored.
# Below are TERM entries, which can be a glob patterns, to match
# against the TERM environment variable to determine if it is colorizable.
TERM Eterm
TERM ansi
TERM *color*
TERM con[0-9]*x[0-9]*
TERM cons25
TERM console
TERM cygwin
TERM dtterm
TERM gnome
TERM hurd
TERM jfbterm
TERM konsole
TERM kterm
TERM linux
TERM linux-c
TERM mlterm
TERM putty
TERM rxvt*
TERM screen*
TERM st
TERM terminator
TERM tmux*
TERM vt100
TERM xterm*
# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
#NORMAL 00 # no color code at all
#FILE 00 # regular file: use no color at all
RESET 0 # reset to "normal" color
DIR 01;34 # directory
LINK 01;36 # symbolic link. (If you set this to 'target' instead of a
 # numerical value, the color is as for the file pointed to.)
MULTIHARDLINK 00 # regular file with more than one link
FIFO 40;33 # pipe
SOCK 01;35 # socket
DOOR 01;35 # door
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file ...
MISSING 00 # ... and the files they point to
SETUID 37;41 # file that is setuid (u+s)
SETGID 30;43 # file that is setgid (g+s)
CAPABILITY 30;41 # file with capability
STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable
# This is for files with execute permission:
EXEC 01;32
# List any file extensions like '.gz' or '.tar' that you would like ls
# to colorize below. Put the extension, a space, and the color init string.
# (and any comments you want to add after a '#')
# If you use DOS-style suffixes, you may want to uncomment the following:
#.cmd 01;32 # executables (bright green)
#.exe 01;32
#.com 01;32
#.btm 01;32
#.bat 01;32
# Or if you want to colorize scripts even if they do not have the
# executable bit actually set.
#.sh 01;32
#.csh 01;32
 # archives or compressed (bright red)
.tar 01;31
.tgz 01;31
.arc 01;31
.arj 01;31
.taz 01;31
.lha 01;31
.lz4 01;31
.lzh 01;31
.lzma 01;31
.tlz 01;31
.txz 01;31
.tzo 01;31
.t7z 01;31
.zip 01;31
.z 01;31
.Z 01;31
.dz 01;31
.gz 01;31
.lrz 01;31
.lz 01;31
.lzo 01;31
.xz 01;31
.zst 01;31
.tzst 01;31
.bz2 01;31
.bz 01;31
.tbz 01;31
.tbz2 01;31
.tz 01;31
.deb 01;31
.rpm 01;31
.jar 01;31
.war 01;31
.ear 01;31
.sar 01;31
.rar 01;31
.alz 01;31
.ace 01;31
.zoo 01;31
.cpio 01;31
.7z 01;31
.rz 01;31
.cab 01;31
.wim 01;31
.swm 01;31
.dwm 01;31
.esd 01;31
# image formats
.jpg 01;35
.jpeg 01;35
.mjpg 01;35
.mjpeg 01;35
.gif 01;35
.bmp 01;35
.pbm 01;35
.pgm 01;35
.ppm 01;35
.tga 01;35
.xbm 01;35
.xpm 01;35
.tif 01;35
.tiff 01;35
.png 01;35
.svg 01;35
.svgz 01;35
.mng 01;35
.pcx 01;35
.mov 01;35
.mpg 01;35
.mpeg 01;35
.m2v 01;35
.mkv 01;35
.webm 01;35
.ogm 01;35
.mp4 01;35
.m4v 01;35
.mp4v 01;35
.vob 01;35
.qt 01;35
.nuv 01;35
.wmv 01;35
.asf 01;35
.rm 01;35
.rmvb 01;35
.flc 01;35
.avi 01;35
.fli 01;35
.flv 01;35
.gl 01;35
.dl 01;35
.xcf 01;35
.xwd 01;35
.yuv 01;35
.cgm 01;35
.emf 01;35
# [url]https://wiki.xiph.org/MIME_Types_and_File_Extensions[/url]
.ogv 01;35
.ogx 01;35
# audio formats
.aac 00;36
.au 00;36
.flac 00;36
.m4a 00;36
.mid 00;36
.midi 00;36
.mka 00;36
.mp3 00;36
.mpc 00;36
.ogg 00;36
.ra 00;36
.wav 00;36
# [url]https://wiki.xiph.org/MIME_Types_and_File_Extensions[/url]
.oga 00;36
.opus 00;36
.spx 00;36
.xspf 00;36

then Bash does it all for you automatically at login time.

The following .dircolors will disable color output even if when using ls --color=always :

Code: [Select]

# Configuration file for dircolors, a utility to help you set the
# LS_COLORS environment variable used by GNU ls with the --color option.
# Copyright (C) 1996-2017 Free Software Foundation, Inc.
# Copying and distribution of this file, with or without modification,
# are permitted provided the copyright notice and this notice are preserved.
# The keywords COLOR, OPTIONS, and EIGHTBIT (honored by the
# slackware version of dircolors) are recognized but ignored.
# Below are TERM entries, which can be a glob patterns, to match
# against the TERM environment variable to determine if it is colorizable.
TERM Eterm
TERM ansi
TERM *color*
TERM con[0-9]*x[0-9]*
TERM cons25
TERM console
TERM cygwin
TERM dtterm
TERM gnome
TERM hurd
TERM jfbterm
TERM konsole
TERM kterm
TERM linux
TERM linux-c
TERM mlterm
TERM putty
TERM rxvt*
TERM screen*
TERM st
TERM terminator
TERM tmux*
TERM vt100
TERM xterm*
# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
#NORMAL 0 # no color code at all
#FILE 0 # regular file: use no color at all
RESET 0 # reset to "normal" color
DIR 0 # directory
LINK 0 # symbolic link. (If you set this to 'target' instead of a
       # numerical value, the color is as for the file pointed to.)
MULTIHARDLINK 0 # regular file with more than one link
FIFO 0 # pipe
SOCK 0 # socket
DOOR 0 # door
BLK 0 # block device driver
CHR 0 # character device driver
ORPHAN 0 # symlink to nonexistent file, or non-stat'able file ...
MISSING 0 # ... and the files they point to
SETUID 0 # file that is setuid (u+s)
SETGID 0 # file that is setgid (g+s)
CAPABILITY 0 # file with capability
STICKY_OTHER_WRITABLE 0 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 0 # dir that is other-writable (o+w) and not sticky
STICKY 0 # dir with the sticky bit set (+t) and not other-writable
# This is for files with execute permission:
EXEC 0
# List any file extensions like '.gz' or '.tar' that you would like ls
# to colorize below. Put the extension, a space, and the color init string.
# (and any comments you want to add after a '#')


You see,  Bash already has the following snippet in /etc/bash.bashrc, the system-wide initialization file (run before user-specific initialization files) for interactive shells:

Code: [Select]

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

It's the test -r ... line that does the magic.  If an user has a dircolors config file, .dircolors, in their home directory, then the dircolors utility is used to read it and emit the bash code to define the necessary environment variables.  Otherwise, dircolors is used to emit the bash code for the default colors.

You do have a very good point that this is poorly documented. Where do you think it would be best documented?

If a section (something about colored output) in the man ls manpage would suffice, then firing an email with a suggested text to the bug-coreutils mailing list should get this fixed in a reasonable timeframe; those developers happen to be quite responsive and friendly in my experience.  On the other hand, this (color adjustment mechanism) is really a bash feature, so it's a bit silly to document in ls manpage how bash controls its behaviour, but how many users would think of looking for ls color adjustment information there?  I don't know, but if you do, I'm willing to help to get this solved.  (I do have accepted patches in these projects, although I am just a nobody.)

FYI, gcc also supports colored output via a similar environment variable, GCC_COLORS.  On my system, /etc/bash.bashrc contains

Code: [Select]

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'


Similarly for GNU grep, GREP_COLORS, although it is unset on my machine.

If these mechanisms -- since they work the same way in all these tools -- would be better described in a man page, then contacting Michael Kerrisk of the Linux man-pages project with a suggestion of a new man page describing these would be a very good idea.  He's quite friendly, and welcomes suggestions and patches; such a new man page might need a bit of discussion on various mailing lists first, to make sure it'll suit both users and devs, but I'm pretty sure it would be welcomed as very useful.

Oh do grow up!

Yes, dad.  You know better, I'm sure.

You still do not realize from your anger that the defaults are just fine for a lot of people, and that you claiming "they are ergonomically poor" is just farting in the wind?  You don't even have better suggestions, just "that's so bad, oh why isn't it like I prefer it?"

My point is that if you truly have a better ergonomic solution that works -- instead of just believing your personal preference is better and everyone else should be using yours too --, we do have the tools to change them; and it is less work than just complaining about it.
For personal use, just add a line in your .profile or create the .dircolors file.  For better ergonomics, send a mail to the maintainers.

See? It is you who is claiming superiority, and blaming the tool, when you yourself are too inept to change anything for the better.  In my opinion, that warrants a snarky remark, followed by actual help in the form of examples.  When you calm down and see how silly your own opinion and behaviour is, you'll see how useful this snarkiness has actually been.  Without it, my suggestion would have been completely ignored.

The funniest thing here is that I value rstofer a lot, and always find the posts interesting and helpful.  If I didn't care, I would have remained silent.  But, because I know rstofer has the capability (and probably affects a lot of other Linux users), I thought a hard nudge was in order to clear the misunderstanding.  You, Cerebus, on the other hand, I'm neutral on: I haven't seen you help others like rstofer often does.

[Cerebus]

Oh do grow up!

Yes, dad.  You know better, I'm sure.

You still do not realize from your anger that the defaults are just fine for a lot of people, and that you claiming "they are ergonomically poor" is just farting in the wind?  You don't even have better suggestions, just "that's so bad, oh why isn't it like I prefer it?"

My point is that if you truly have a better ergonomic solution that works -- instead of just believing your personal preference is better and everyone else should be using yours too --, we do have the tools to change them; and it is less work than just complaining about it.
For personal use, just add a line in your .profile or create the .dircolors file.  For better ergonomics, send a mail to the maintainers.

See? It is you who is claiming superiority, and blaming the tool, when you yourself are too inept to change anything for the better.  In my opinion, that warrants a snarky remark, followed by actual help in the form of examples.  When you calm down and see how silly your own opinion and behaviour is, you'll see how useful this snarkiness has actually been.  Without it, my suggestion would have been completely ignored.

The funniest thing here is that I value rstofer a lot, and always find the posts interesting and helpful.  If I didn't care, I would have remained silent.  But, because I know rstofer has the capability (and probably affects a lot of other Linux users), I thought a hard nudge was in order to clear the misunderstanding.  You, Cerebus, on the other hand, I'm neutral on: I haven't seen you help others like rstofer often does.

The only person who seems to be exhibiting anger here is you, shouting at people for taking an attitude that you have imagined they are taking. Then you further go on to assume that the two people who have an issue with the default colours are incapable of changing them or overriding the default coloured ls alias that most/many linux distributions ship with. I know I can do it, and do, and I bet rstofer can too.

Even if we can't or couldn't or won't alter the defaults, it doesn't invalidate our opinions that some of the defaults are horrible. You seem to think that someone whose opinion differs from yours is a valid excuse to belittle and insult them and claim that they have said or done things that they haven't. That's neither adult, nor civil behaviour. You seem to feel the need to force your opinion on others on what is, when all is said and done, a trivial issue, by berating them, inventing things like "It is you who is claiming superiority" when neither rstofer or I have, even implicitly, claimed any superiority, claiming that we're incompetent to change the behaviour in question, that we're "blaming the tools" and so on, when all we're doing is voicing the opinion that some of the default colour choices are ergonomically poor. If you overreact and become unpleasantly ill-mannered over something this trivial, what do you do when someone disagrees with you about something important? Frame them for a crime? Stab them?

The dircolors defaults are objectively poor, not in their entirety but in places.

An example from Debian, with standard system defaults^*:



Note that both setuid files and files with the sticky bit set are hard to read with the default colour scheme.

They are trying to highlight setuid files, that's good. At the same time they make the filenames hard to read, that's bad. That's particularly problematic if someone's maliciously changed a link to a setuid file and you don't spot that it's the wrong file that's linked to because it's hard to read at a glance. Try an 'ls -l' of /sbin and see if you can easily make out what's linked to what. (There are better ways of ensuring the integrity of system files than hoping to find malicious setuid changes by happenstance, but it's surprising how many systems problems get fixed by someone going "Hold on, what's that file doing there?" while they're working on something else.)

I'm assuming that you know what you're talking about, which is perhaps wrong of me; perhaps you've never encountered this and therefore have never seen the problem, after all setuid and sticky bits are things that one wouldn't expect an average user to encounter all that often, if at all, whereas experienced system administrators have to deal with them all the time.

^* To be clear, standard defaults for ls colours, the settings for both prompt colours and ls time stamps are my normal overrides of the defaults.

[Nominal Animal]

You seem to think that someone whose opinion differs from yours is a valid excuse to belittle and insult them

No, I don't.  Reread the thread to see that.

I use a snarky, spiky response to raise heckles, then show factual help and advice on solving the issue.  It works: on those capable, it makes them think.  On those not capable, it makes them retaliate.  If I omit the snarky bit, the advice is ignored.  So, I find the snarky bit necessary when others might be lead astray by the associated misconceptions, as the most effective way to correct the misconceptions.

That's neither adult, nor civil behaviour.

Go play SWJ on twitter, please.  Here, that sort of indignant posturing is met with laughter, as is proper.

all we're doing is voicing the opinion that some of the default colour choices are ergonomically poor

Unless you prove that by showing a better set, that is just farting in the wind: no positive value to anyone, just stinking up someone elses air.

I could voice my opinion that you are an <X> with an inflated <Y>, but doing so is also just farting in the wind, and contributes nothing to this thread.  What you write here shows that already, and those who care, will see it for themselves; there is absolutely no reason for me to do so.


As I mentioned above, I have not encountered anyone who had a better set of default ls/grep/gcc ANSI color outputs.

What I do have encountered, and have helped others set, quite a few times, is adjust the representation of those 16 colors in their preferred terminal emulator and text editors, including background color, to better suit their particular use case.  This is the key point here.

The default color set is explicitly designed to not be optimal for anyone, but to work with both dark and light backgrounds.  Different terminal emulators, and different desktop environments, default to a different terminal background color, and bash cannot detect it in a portable manner.  So, the default set is a compromise, and must be treated as such.

This is typical to Linux: the defaults work for most situations, but to make the system work well for you, you need to override them.

If the developers assumed, like you do, that terminal emulators typically have a white background, then they could have picked a better set; but that set would almost certainly be completely horrible for the other half of terminal emulators that default to a dark background.  For example, on this Ubuntu 18.04 LTS installation, gnome-terminal, mate-terminal, terminator, and xterm all default to a dark background.

For Xterm, it depends on your local /etc/X11/app-defaults/XTerm-color file, and what you have set for the *VT100*background: setting.

The developers, however, have been completely open about this, and have tried to make it as easy as possible for users to override the color sets, both the ANSI color sequences used for different elements via LS_COLORS/GCC_COLORS/GREP_COLORS, and the actual display representation of those colors, to match their own workflow: their preferred terminal emulator color scheme including background color, and use cases.

Can you see the fundamental disjoint here?  That the defaults are not intended to be polished or ergonomic for any specific user case like yours, but are a set that works in all situations well enough?  And that that is exactly the huge alien idea I'm trying to get you to understand?

Commercial products need to have a specific supported polished configuration, with users on their own if they deviate from it.
Some push that to Linux also, and that is what I oppose.

It is a bug of sorts to have to dig up through documentation (other than a quick man -k colors, man bash, or man ls) to find this functionality, and if rstofer has some advice on where the documentation should be for users to be more likely to find it, I've already offered to help push a fix to that.  (I now think man dircolors would be the best place, but it'll be next Thursday I talk to suitable test victims users to see if they'd find the advice there.)

But to claim that the defaults are bad is wrong, because the defaults are supposed to work on different background colors, and therefore cannot be optimal or even particularly ergonomic for your case; and to not realize that your particular terminal background color is not a given by any means, is just silly.  Shellfish, even.

The only reasonable action, aside from making the documentation better, is to customize the tool to fit your needs best.

See?  I've been trying to help you see this seemingly alien idea all along.  I'm not angry, I'm not shouting; I'm just using whatever tools I have to point it out.  If I do it nicely and in a politically correct manner, the idea is lost among the babble.  The snarkiness itself is just a tool to get others to notice the alien idea here.

So calm down and look at the world you've missed for your presuppositories.

[Cerebus]

But to claim that the defaults are bad is wrong, because the defaults are supposed to work on different background colors, and therefore cannot be optimal or even particularly ergonomic for your case; and to not realize that your particular terminal background color is not a given by any means, is just silly.  Shellfish (sic), even.

The particular defaults that I find bad explicitly set the background colour and then explicitly set a low contrast foreground colour on top of it - the basic window background colour doesn't come into it, so the argument that they are chosen to work well on a range of background colours is fundamentally flawed.

Shorely (sic) this is obvious, even to someone as crabby as you.  (Not personally a fan of using smileys on such an obvious joke as this, but I suspect subtlety might be lost on you.)

See?  I've been trying to help you see this seemingly alien idea all along.  I'm not angry, I'm not shouting; I'm just using whatever tools I have to point it out.  If I do it nicely and in a politically correct manner, the idea is lost among the babble.  The snarkiness itself is just a tool to get others to notice the alien idea here.

That sounds very much like an almost verbatim admission that the rudeness and other low behaviour is just the attention seeking it appears to be. One doesn't have to be rude or abrasive to get people to listen to one, in fact quite the reverse is generally true unless one is trying to be a demagogue.

So calm down and look at the world you've missed for your presuppositories.

I think you mean "presuppositions", a suppository is something very different...

It's quite clear that any appeal to you not to be needlessly rude or abrasive will fall on deaf ears, as it is also clear that any suggestion that there might be some poor choices in the default dircolors scheme isn't going to get past your rigid thinking on the subject, so I'm outta here. I'm betting that you're exactly the type who isn't going to let me have the last word on this, so feel free to rattle on about it, but I won't be listening.

[SiliconWizard]

Are you guys realizing you're fighting over colors? Seriously...

[Nominal Animal]

Shorely (sic) this is obvious, even to someone as crabby as you.

It reads just fine on my terminal:

Not optimal, sure, but still legible.  The reason it is not black (su=30;41 instead of su=37;41) is that black on red background is already used for files with capabilities, and the other possible standard colors are worse.  You could argue that they should be swapped, because setuid binaries are more common than files with capabilities, and black-on-red is indeed more readable than gray-on-red.

(In many situations, though, file capabilities are more appropriate than setuid.  For example, if a process needs to bind to a TCP port 1-1024, it is better to give it the CAP_NET_BIND_SERVICE, via sudo setcap cap_net_bind_service=pe /path/to/binary, and run that service as a dedicated user, rather than run it as root.  That is, the counterargument to the argument above is that we should use file capabilities more often than setuid.)

I think you mean "presuppositions", a suppository is something very different...

Wordplay.

It's quite clear that any appeal to you not to be needlessly rude or abrasive will fall on deaf ears

As I explained, rudeness/abrasiveness was necessary, because otherwise the advice is ignored.  I know from long experience.

it is also clear that any suggestion that there might be some poor choices in the default dircolors scheme

Choice implies a something better exists.  I have not seen anything better, so claiming the choices poor is a baseless claim.  Prove it, and I'll apologise profusely.  Do note that it must work for different terminal backgrounds, and you cannot simply ignore all the other things ls colors (including things like make the foreground black making setuid files indistinguishable from files with capabilities).

My entire point is that these defaults are intended for you to replace with something that works better for you, unless the default happens to suffice.  I have seen users who remove the aliases (or replace them with --color=never), and I have shown others how to adjust what "red" looks like in their terminal, but I have not seen anyone with a better set of LS_COLORS.

In short, I'm trying to get you to see that this kind of thing happens in almost all Linux applications (aside from Gnome, systemd, and the other ones who steer away from the Unix philosophy, and the idea that the user is in total control of the tool), and you should feel it normal to adjust the defaults.
This is because Linux works on so many different architectures, situations, and workflows, that the defaults are not going to cut it, if you want comfort, ergonomics, or efficiency.  It is not a fault; it is a built-in aspect that goes so deep that most people never realize it when they adopt the idea.

I'm betting that you're exactly the type who isn't going to let me have the last word on this, so feel free to rattle on about it, but I won't be listening.

Well, like I said, my goal was to point you to the idea of customization-as-a-necessary-part, and make sure that newbies reading this thread have at least a possibility to see, perhaps even grasp that idea.  I don't mind it if this made you hate me, if in time this affects even one or two newbies' approach.

You see, the entire idea is core to how to make Linux work for someone.  If you find you don't like something in Inkscape or Gimp, rather than go on Twitter lambasting how poor their defaults are, you go and modify the configuration files to make them work better.  You tinker with them a bit, maybe modify the code if the configuration files don't have enough knobs.  If you succeed, you let the maintainers know of the better way.
This way there is more chance for everybody to win.

It also means that if you are a team leader, CTO, or in a similar position, and you see that your current Linux tools do not work well enough for you, you know what to do: get someone to analyse your workflows, and propose a better configuration to suit those workflows.  If you cannot afford to pay for completely new software, you might be able to let your workers dedicate a fraction of their working time to write better tools, and even set a small bounty for anyone who succeeds.

This is completely different to what most companies do nowadays.  They buy off-the-shelf software, and that's it.  It is the core idea that differs.

Are you guys realizing you're fighting over colors? Seriously...

I am actually trying to show that if you intend to use Linux efficiently, you need to understand that the defaults are not recommended, they are primarily more like a fallback that should work in all situations, and secondarily something that works well enough for most people; and that users (or system administrators for organisations) should find it natural to modify the defaults, because this applies to most Linux software.

Colors are just a very good example of this situation.  Like I said, I use a custom theme (variant of Oblivion), and change my terminal color representation (RGB codes used to represent the standard 16 colors), and often help others do the same to get more comfortable; I use very low brightness displays to keep eye strain low.  I expect this to be utterly common.

Having users I know are adept in Linux not understand the need and importance of customization is alarming to me: they're having to deal with an uncomfortable tool, for no purpose!  I want to change that, but not by agreeing to force their preferences on anyone else.

[rstofer]

Are you guys realizing you're fighting over colors? Seriously...

It's kind of a big deal because it is far from intuitive how to deal with the issue.  Right up front, I acknowledge that the problem is all mine;  I have defective red-green color vision.  There are color combinations I simply can't see.  My problem, nobody needs to cater to it.  But given the opportunity to bitch about LS_COLORS, I'll take it!

I understand that the colors can be redefined in a user file but I wish people who choose colors would stay away from red and deep magenta.  Web pages used to be particularly problematic.  People would experiment with 'pretty colors' on their pages not understanding that their content just became invisible.  The default coloring of the Arduino IDE is awful!  There is no possible way I can read the error messages and changing the color scheme is far from straight forward.  You would expect it to be in <menu><edit><options> but no such luck.

I'm not a singularity, 8% of the adult male population, but only 1% of the adult female population, have some defect in their color vision.  It manifests in different ways because I can easily see stop lights and big red firetrucks but I can not tell the difference between dark blue and purple.  At least not always.

But it's my problem, I'll own it!  And I'll probably keep bitching about LS_COLORS

https://www.allaboutvision.com/conditions/colordeficiency.htm

[rstofer]

If you haven't tried 'cool-retro-term' as your terminal, you're missing out on something amazing.  No, you won't get colorized directory listings but what you will get is a retro look back at the amber on black screens of yesteryear along with some amazing graphic effects.  There can be a scrolling interference fringe in the background, the left edge of the display area can be warped and the first character on each line will be slightly mangled just like on the real terminals of the era.  There are other color screens, some of which are more appropriate to laptops (lacking graphic horsepower).

I use the terminal a lot and I don't always remember to pull up 'cool-retro-term' but I do have an icon on the desktop for doing it.  When I use it, I am reminded of the late '70s when I was doing time share with the campus computer while in grad school.  A 110 baud acoustic coupler, something predating the ADM-3 terminal I bought about half way through and being actually amazed at the speed of the school's Data General Basic.  In the same timeframe, I bought the Altair 8800 which I still have.  The ADM-3 is long gone but I still have an TV950 which is a very nice terminal

If you have to use the terminal, it might as well be 'cool'.

https://github.com/Swordfish90/cool-retro-term

[Nominal Animal]

I have defective red-green color vision.  There are color combinations I simply can't see.  My problem, nobody needs to cater to it.

No, but there are lots of folks who are willing to help, if you'll do the hard work (testing suggestions, giving thoughtful feedback, help with documentation).

For example, I would recommend you consider redefining the colors in your terminal emulator instead.  There are only sixteen, so perhaps it would be possible to use actual colors/shades you can distinguish well?  Yes, they are intended to be black-red-green-yellow-blue-magenta-cyan-white and their bright/bold counterparts, but it is just a convention, nothing put in stone.  "red" is often used for errors, "green" for success messages, but otherwise they are basically arbitrary.

As you point out, red-green is difficult for many to perceive (and I believe some countries use blue instead of green in streetlights partly for that reason?), so having a set of 16 colors used in terminal emulators that avoids those associated difficulties, would most definitely be useful!

The problem is, that those of us with normal color vision, cannot really design or even test such palettes.  (I could write a numerical simulator using CIE Lab color space, selecting the 16 colors using an Lb plane (a component is red-green difference, you see), and find some candidate sets, but I have no way of telling how those with red-green perception difficulties would perceive the colors, or choose the "best" one!)

I'm really hoping you see what I am getting after here.  If people like you only complain, nothing will get better.  But, if we treat the defaults as just a fallback or a tentative suggestion, we can find something that works much better for you.  And if we find it, we can push it upstream, and see if it works for others as well.  See?

I'll probably keep bitching about LS_COLORS

But.. wouldn't it be nicer to make it work in your favour instead? 

If you want a test pattern, you can run

Code: [Select]

for B in 40 41 42 43 44 45 46 47 ; do for I in '' '1;' ; do for F in 30 31 32 33 34 35 36 37 ; do printf '\033[%s;%sm %s;%s \033[0m ' "$I$B" $F "$I$B" $F ; done ; printf '  ' ; done ; printf '\n' ; doneto see all 128 of the normally-used color combinations.  The colors should be alterable in your terminal emulator menus somewhere.

[rstofer]

I appreciate the effort but I don't see myself spending any time on this.  Yes, for me, it's a problem, but it doesn't follow that I want to spend any time on it.  I just comment out the aliases and it's over and done.

And then there is syntax coloring in vi and nano.  Again, depending on the colors, the text absolutely disappears.  Who thought dull red on black would work?

[bd139]

Wow this thread is a rollercoaster

I run without colours (force xterm-mono) because quite frankly getting everything to work properly is a ball ache. Also I hop around environments and machines a lot and like hell i’m going to futz with my profile and vimrc on every damn machine. It’s just not worth it.

On my control node, a VM in virtual box in windows 10 (fuck running native), it’s the same. And my PS1 is set to $ like a V7 machine. I can remember where I left my sunglasses and cwd fine thanks.

Every time I see someone with technicolour vomit all over their terminal or UwUs and ASCII art in their PS1 I want to punch something. 

In fact it was only a few weeks ago a devops colleague fork bombed the ssh relay box in a spectacular profile customisation fail.

“I can’t login. It just hangs”

“Ps on box ... ooh 1024 bash shell processes”

Good job I set up ulimits properly, which I had time to do because I wasn’t fucking around trying to read red on blue text in vim.

[nctnico]

I appreciate the effort but I don't see myself spending any time on this.  Yes, for me, it's a problem, but it doesn't follow that I want to spend any time on it.  I just comment out the aliases and it's over and done.

I'm not color blind but I do spend time on the color scheme of the terminals in Linux when running in X-windows.

[SiliconWizard]

I have a .bashrc that fits me well and I copy it to any home directory I use. Simple and effective. You just have to worry about customizing it once.