[Terminal] some default color settings are hard to read

[scottmc]

Blue text with a green highlight background is just plain hard to read. Perhaps this can be defaulted to a better color combination. See screenshot.

[scottmc]

results from running ls in terminal, showing an almost unreadable color combo

[jackburton]

We are using the same default colors as the Gnome terminal. They are hard to read there too. With a black background, they look much better, though.

[jackburton]

Replying to jackburton:

We are using the same default colors as the Gnome terminal. They are hard to read there too. With a black background, they look much better, though.

Just to be clear: I'm not saying that since it looks bad in Gnome, too, it's okay. Just that we're following some sort of standard, and that the colors have to be checked with different backgrounds (at least black, and white). BTW a black background makes much more sense (even by default, IMO), since it's less flashy and more readable.

[scottmc]

If you look at the screenshot I posted, you'll see the issue is the green chars with a blue highlight background. I'm not so sure that that becomes easier to read if you change the white background to black though. Where can this color combo even be adjusted? I couldn't locate it in any of the menus.

[axeld]

The colors itself are fine, it's just the combination that "ls --color" uses that should be adapted. Green on blue just can't look good in any case :-)

[humdinger]

dircolors -p > /boot/system/etc/.dircolors

produces a list of the used default colors. I have looked for blue-on-green (34;42) which was only found for STICKY_OTHER_WRITABLE and changed that to black-on-green (30;42).

Putting

eval `dircolors -b /boot/system/etc/.dircolors`

into /boot/system/etc/profile should load these new color on every Terminal start. I couldn't test, because I couldn't find anything that was blue-on-green to begin with. I attached the slightly altered .dircolors. Maybe someone has another itch to scratch and modifies a few more entries before committing it together with the changes to the profile.

[humdinger]

blue-on-green -> black-on-green

[pepol]

The problem was checked during GCI 2011. It still looks the same with default settings on hrev43238. Also (for someone who doesn't know these things...), these colors are used for 777 chmod-ed directories.

[korli]

Hi Prasad,

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

[korli]

I forgot to write: a comment header in colorls.sh would be nice too:)

[Prasad]

Replying to korli:

Hi Prasad,

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

I am not sure I understand you correctly, but seems like the latest diff in dircolrs.hin is already reflected in the latest source code

~> echo $LS_COLORS | tr -s ':' '\n' | grep -i lz
*.lzh=01;31
*.lzma=01;31
*.tlz=01;31
*.lz=01;31

~> echo $LS_COLORS | tr -s ':' '\n' | grep -i cgm
*.cgm=01;35

~> echo $LS_COLORS | tr -s ':' '\n' | grep -i emf
*.emf=01;35

The latest commit for dircolors.hin shows

commit 9904bec57614b6d4aee9a50344435fada6dcf1ee
diff --git a/src/bin/coreutils/src/dircolors.hin b/src/bin/coreutils/src/dircolors.hin
index 91ddcb6..6a4b1e3 100644
--- a/src/bin/coreutils/src/dircolors.hin
+++ b/src/bin/coreutils/src/dircolors.hin
@@ -1,8 +1,7 @@
 # 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, 1999-2009
-# Free Software Foundation, Inc.
+# Copyright (C) 1996, 1999-2010 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.
 
@@ -116,6 +115,7 @@ EXEC 01;32
 .Z   01;31
 .dz  01;31
 .gz  01;31
+.lz  01;31
 .xz  01;31
 .bz2 01;31
 .bz  01;31
@@ -175,6 +175,8 @@ EXEC 01;32
 .xcf 01;35
 .xwd 01;35
 .yuv 01;35
+.cgm 01;35
+.emf 01;35
 
 # http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
 .axv 01;35

[Prasad]

Replying to korli:

I forgot to write: a comment header in colorls.sh would be nice too:)

I will attach another patch

[Prasad]

Added a patch https://dev.haiku-os.org/attachment/ticket/4494/0001-Change-color-scheme-for-other-writable-directory.2.patch

The patch adds additional comments in the colors.sh file.

[korli]

Replying to Prasad:

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

I am not sure I understand you correctly, but seems like the latest diff in dircolrs.hin is already reflected in the latest source code

Your patch modifies dircolors.h which is a generated file based on dircolors.hin. Thus your modification of dircolors.h might be lost anytime dircolors.h is regenerated (or coreutils is updated or outsourced). It should take place at line 83 if I'm not mistaken.

[Prasad]

Replying to korli:

Replying to Prasad:

it seems your patch doesn't include changes for src/dircolors.hin. Could you please add this and update the patch? Thanks.

I am not sure I understand you correctly, but seems like the latest diff in dircolrs.hin is already reflected in the latest source code

Your patch modifies dircolors.h which is a generated file based on dircolors.hin. Thus your modification of dircolors.h might be lost anytime dircolors.h is regenerated (or coreutils is updated or outsourced). It should take place at line 83 if I'm not mistaken.

Thanks I was not aware of the fact dircolors.h is auto-generated. I have attached another patch [https://dev.haiku-os.org/attachment/ticket/4494/0001-Change-color-scheme-for-other-writable-directory.4.patch ] please check if it is suitable.

However, I am not able to figure out the reason for committing the dircolors.h in the repository. Since it is auto-generated, it could have been generated while building the source itself.

[diver]

Prasad, could you take a look at #1944 as well?

[Prasad]

Replying to diver:

Since I am new here, I would like to know the reason the patch has been removed. Does this mean it is included in the mainline? or Is the patch not working on your machine? Please educate.

Prasad, could you take a look at #1944 as well?

Thanks Diver I will have a look.

Regards, Prasad

[luroh]

Since I am new here, I would like to know the reason the patch has been removed.

The missing patch flag is simply a bug that was triggered by diver adding his comment. A few days ago, Trac was upgraded and we are experiencing some fallout. This particular bug is being tracked in #9058.

[Prasad]

Replying to luroh:

Since I am new here, I would like to know the reason the patch has been removed.

The missing patch flag is simply a bug that was triggered by diver adding his comment. A few days ago, Trac was upgraded and we are experiencing some fallout. This particular bug is being tracked in #9058.

oops, thanks a lot for clarification.

I wish this patch would be applied soon so that I no longer have to track it.

[leavengood]

I will try to apply this patch tonight, probably 6 to 8 hours from when this comment was left.

[Prasad]

Replying to leavengood:

I will try to apply this patch tonight, probably 6 to 8 hours from when this comment was left.

Can this be applied today?

[korli]

Applied in hrev44712

[kallisti5]

picked for R1A4

Tested as ok, going to close for now. Feel free to re-open if any issues still exist.