Colors when on unraid console


Recommended Posts

I guess I'm getting old... I simply can not easily read some of the text on the unraid console when I get in there. The green background highlighting with blue text messes with my eyes.

 

Is there any way to change that?

 

Example, see the text on the directory listing:

Capture.PNG.76dbee75c8a52e01d2a98b77f6b78dbc.PNG

Edited by JasonJoel
Link to comment
15 hours ago, Squid said:

@JasonJoel I've got a 12" monochrome CRT in my garage I'm willing to part with. Cheap!

 

Just can't bring myself to part with it quite yet. If you say no to it, I might just have to toss it in the bin...

2020-01-01 10.56.12.jpg

Link to comment
  • 3 months later...

...came here to look for a solution to the same issue.

 

The problem as I understand it, is in the environment settings of "LS_COLORS" and "LS_OPTIONS".

Normally something you would specify in your .bashrc file.

For user root in unRAID, a .bash_profile exists, but I could not add any new LS_OPTIONS or LS_COLORS setings and make them stick.

 

I now solved this issue by simply adding "alias ls="ls --color=never" to the end of the .bash_profile...now everthing is simple, without colors.

IMHO much better than before ;)

Who the heck made blue with a green background the default ??

  • Like 1
Link to comment
On 12/31/2019 at 11:39 PM, JasonJoel said:

I guess I'm getting old... I simply can not easily read some of the text on the unraid console when I get in there. The green background highlighting with blue text messes with my eyes.

 

Is there any way to change that?

 

Example, see the text on the directory listing:

Capture.PNG.76dbee75c8a52e01d2a98b77f6b78dbc.PNG

You can change with the environment variable LS_COLORS. The dircolors command allows you to import a new set of colors:

eval `dircolors dircolorsfile`

e.g.

image.png.aabe26ad215c4c2884b936c3b3fc5ce8.png

Edited by cinereus
Link to comment
  • 2 months later...
  • 2 months later...
On 4/19/2020 at 2:41 PM, Ford Prefect said:

...came here to look for a solution to the same issue.

 

The problem as I understand it, is in the environment settings of "LS_COLORS" and "LS_OPTIONS".

Normally something you would specify in your .bashrc file.

For user root in unRAID, a .bash_profile exists, but I could not add any new LS_OPTIONS or LS_COLORS setings and make them stick.

 

I now solved this issue by simply adding "alias ls="ls --color=never" to the end of the .bash_profile...now everthing is simple, without colors.

IMHO much better than before ;)

Who the heck made blue with a green background the default ??

I would appreciate info on how to do this. My eyes are getting worse and I really have trouble reading with the highlights

Link to comment

Well, of course the .bash_profile is in the home directory of each user that you use/want to connect with, into a CLI (shell/bash) session, i.e. via ssh.

Normally this is user "root", when you are using the terminal button/icon from the dashboard, so in this case the file location is /root/.bash_profile

 

You can edit & save it there, but it will be gone after each reboot.

In order to persist this setting, you should edit & save the "go" script, which is located in /boot/config.

 

This is what I added into my go script:

# fix console colors
echo "alias ls=\"ls --color=never\"" >> /root/.bash_profile

...hope this helps.

Link to comment
  • 7 months later...
On 10/22/2020 at 9:22 PM, Ford Prefect said:

Well, of course the .bash_profile is in the home directory of each user that you use/want to connect with, into a CLI (shell/bash) session, i.e. via ssh.

Normally this is user "root", when you are using the terminal button/icon from the dashboard, so in this case the file location is /root/.bash_profile

 

You can edit & save it there, but it will be gone after each reboot.

In order to persist this setting, you should edit & save the "go" script, which is located in /boot/config.

 

This is what I added into my go script:


# fix console colors
echo "alias ls=\"ls --color=never\"" >> /root/.bash_profile

...hope this helps.

 

Awesome, finally a readable web console, thanks, I shared this in another thread where people were looking for a solution.

Link to comment
  • 3 months later...
On 1/1/2020 at 9:58 AM, FreeMan said:

@JasonJoel I've got a 12" monochrome CRT in my garage I'm willing to part with. Cheap!

 

Just can't bring myself to part with it quite yet. If you say no to it, I might just have to toss it in the bin...

2020-01-01 10.56.12.jpg

Hey... I played Everquest on a system with one of those.  Made it easier to find rare Yew Leaves.  In greyscale they were quite visible.

Link to comment
  • 3 months later...
  • 4 weeks later...

I realize this is an old topic, but I wanted to chime in with an alternate fix for this.  First off, it's worth noting that on Ubuntu at least, this the default color for a directory that is set with world writeable permissions (ie, anyone can write to it).  And while it's hard to read, on Ubuntu, it's easier to read than the unRAID web console implementation.  My guess is that in linux they really want you to know that this folder is basically insecure.

 

While you could use the color=never option, I actually like having color, just not this color.  So this is what I did.

 

1. I made a backup of /etc/DIR_COLORS

2. I edited the /etc/DIR_COLORS (nano /etc/DIR_COLORS) and changed the lines

 

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

to

STICKY_OTHER_WRITABLE 01;33 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 01;33 # dir that is other-writable (o+w) and not sticky

 

This file talks about what those numbers are, and they explain them in the comments before this section.

 

# 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


So you see that 34;42 is blue text on green background and changed it to bold (01) yellow (33) text with no background.

 

3. This changes this at the system level, but it likely will not survice a reboot, so, I made a backup of this file in the config area.

cp /etc/DIR_COLORS /boot/config/DIR_COLORS.sean

 

I don't reboot my unraid server very often, but, when I do, then then login and copy my backup from config to the /etc/DIR_COLORS.  Although I haven't done this yet, and it'll likely be months before I actually verify this part.

 

So now ls still shows me that those files are world writeable, but it's easier to read (for me).

 

image.png.9cc9097c0b157ffff8c2bdb9921259e3.png

 

Given that these folders are created by unRAID is there an option in unRAID to never create world writeable folders? (because that would solve the problem as well, since they'd just show the normal blue)

 

  • Like 2
Link to comment
  • 3 months later...
  • 1 month later...

I don't know why, but for some reason it didn't work to edit /etc/DIR_COLORS, /root/.dir_colors, or /root/.dircolors (but I think this does work on other linux systems I've used, so I'm stumped). 

 

What did work was to change the following line in my .bashrc:

test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"

to 

test -r ~/.dircolors && eval "$(dircolors -b | sed -E 's/30;42|34;42/01;33/g')"

 

Here I'm just using sed to replace any occurrences of 30;42 or 34;42 in the default colors with 01;33 before doing eval to make the change. If your .bashrc doesn't have a section with this line, you can add the following chunk anywhere: 

 

# enable color support of ls and also add handy aliases
if command -v dircolors &> /dev/null; then
    test -r ~/.dircolors && eval "$(dircolors -b | sed -E 's/30;42|34;42/01;33/g')" # I can't get the default line below to work on UNRAID but this works.
    #test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto --quoting-style=literal' #GNU coreutils version
    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

 

Link to comment
  • 2 months later...
On 7/3/2022 at 10:46 AM, ultra_bread said:

 

# I can't get the default line below to work on UNRAID but this works.
#test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"

 

The reason why that doesn't work is that you're essentially trying to evaluate a shell script twice.

 

1. The content of ~/.dircolors is a shell script

2. dircolors -b ~/.dircolors will evaluate the script and print the results, which is empty

3. eval "$(dircolors -b ...)" will evaluate the empty string

 

At least that's how I think it is.

 

Just copy /etc/DIR_COLORS to ~/dircolors and work with that instead. It's much easier to read and maintain, and it prevents misunderstandings.

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.