dietpi-update), before prompting reboot (php code issue)Hum, yeah seems to be. Looks like terminals handle color codes all different. Test would be in this case if echo -e '\e[90mTest\e[0mTest' actually shows different colours, thus \e[90m != \e[1;30m is handled differently on that terminal, or if gray itself is a problematic color on some terminals/screens.
@MichaIng
Yep, its definitely a terminal emulator limitation.
Test:
echo -e "\e[1;30m test\e[0m\e[90m Test \e[0mTest"
@Fourdee
Hmm, 90m is not understood by many terminals and 1;30m is too dark on some terminals (90m would have been too, if understood?). Maybe we find a colour code in between, that is understood by all, maybe via something like \e[50;50;50m as RGB code? At least that scheme is understood by VirtualBox terminals, as we use this for banner separation lines.
After soccer match is finished, I will play around.
@SuBLiNeR @ghost
Hmm, both users deleted 馃.
Whatever, first the different obvious grey possibilities:

\e[90m = \e[1;30m on PuTTY and \e[90m has no effect on Jessie VM (VirtualBox) terminal, same for all above 90.\e[2m) is not understood by PuTTY and gives very strange result on all VirtualBox terminals.\e[38;5;XXX codes (https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-prompt), which are supported by Jessie VM terminal as well, but it seems there is no colour possible between normal white and the already too dark (in this one case) grey:

So it looks like so far we were "lucky" that the affected terminal did not support \e[90m, because it would have been too dark as well. But as there is nothing possible in between this grey and normal text colour on some terminals, we have the choice between plague and cholera 馃槥:
@MichaIng
Stay with previous solution, but not predictable, since unsupported on some terminals and possibly too dark as well on others. But at least we didn't have any complains with the old colour code, besides me, having just normal white colour for INFO messages on VM Jessie terminal. But better white than too dark to read and it was really just Jessie. On Stretch+Buster \e[90m worked. Just thought it might be unsupported by more terminals, also as it is not listed on most web results about the topic.
Yep, lets revert the change for now as our current support level is Stretch. We'll do a hotfix in the next day or two.
Allo GUI:
@MichaIng
I use the following for reference colour codes:
https://misc.flogisoft.com/bash/tip_colors_and_formatting

Hotfix release ETA tomorrow.
Both issues are now resolved. Marking as completed.
Hotfix v6.11 will be released later today.
@Fourdee
Your link btw. also contains terminal compatibilities, e.g.:
Terminal | Bold | Dim | Underlined | Blink | invert | Hidden | 8 | 16 | 88 | 256 | Comment
-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
Linux TTY | ok | - | - | - | ok | - | ok | ~ | - | - | Specials colors instead of Dim and Underlined. Lighter background instead of Blink, Bug with 88/256 colors.
echo $TERM ==> Linux, so that should be it and explains, why dim shows this funny blue, and \e[90m (16) is not supported. ~ actually means "supported in special way", result is support on Stretch+Buster but not on Jessie, maybe this is it.
Also the green \e[38;5;XXXm banner line appears yellow and huge steps between 88/256 colour grey scales.
@MichaIng
Good spot 馃憤
Ideally, we should detect term type, then set the required colour code:
eg - green='\e[38;5;XXXm'
if [[ term = linux ]]
green='the other one'
Then use those colours throughout scripts, as a global if required?
But this is a minor issue, we can resolve when time permits.
@Fourdee
Yeah definitely a minor, especially since the bigger issue is the supported grey on displays, where it's too dark to read 馃. Unsupported grey as white is not what we intended, but it doesn't hurt much.
Auto detection is an idea, but we theoretically would need to verify it on all kind of terminals and all distros, since [[ $TERM == linux ]] has with our current colour codes just issues on Jessie as said.
Ideally from my point of view would be to stay with definitely supported colour codes, so we don't need to worry about the terminal any more. I am now thinking that \e[1;30m is in those cases too dark, where "bold" is actually handled as bold instead of just rising the brightness, because of \e[30m being black. But then, there is no grey at all, as "dim" is widely unsupported. Ah really, I would just leave it as it is now 馃ぃ...