Skip to content

Instantly share code, notes, and snippets.

@wyattanderson
Created October 5, 2011 15:38
Show Gist options
  • Save wyattanderson/1264760 to your computer and use it in GitHub Desktop.
Save wyattanderson/1264760 to your computer and use it in GitHub Desktop.
Unique Hostname Colorization
# Calculate a short checksum of the real hostname to determine a unique color
if [[ $TERM =~ "256color" ]]; then
host_color="38;5;$((16 + $(hostname | cksum | cut -c1-3) % 256))";
else
host_color="1;$((31 + $(hostname | cksum | cut -c1-3) % 6))";
fi
@lkraav
Copy link

lkraav commented Oct 13, 2011

good job getting this rolling, i was looking for some universalish checksum approach to this. there's a problem though with visibility issues. depending on whether you have a light or dark backgrounded terminal, you need to restrict colors sets to those that are actually visible against the respective background. here this laptop hostname produced lime green hostname against solarized light background, my eyes wanted to start screaming. gonna take a shot at this.

@wyattanderson
Copy link
Author

I think the algorithm is ripe for improvement; the checksum idea came from here, all I did was add some rudimentary 256color support. There're definitely better ways to map hostnames to colors in a more visually informative manner. I'll hack on this a bit.

@lkraav
Copy link

lkraav commented Oct 13, 2011

thanks for the link. i'm looking at xterm-colortest -w output http://i.imgur.com/SEO41.png and it would seem you can split the palette in half for light and dark, i.e. for light background you can do bad_color - 18 = good_color. problem is afaik there is no way to really determine what color scheme client is using systematically aside from COLORFGBG variable (http://stackoverflow.com/questions/2507337/is-there-a-way-to-determine-a-terminals-background-color/7760031#7760031) and even this seems to restricted to rxvt and compatibles, i.e. xterm for example doesn't set it. but i guess it is reasonable to make user set this for themselves if they desire this functionality?

btw im also doing USER_COLOR with this now :)

@lkraav
Copy link

lkraav commented Oct 13, 2011

ok so coming up with a comprehensive light vs dark solution is currently more than i can handle. my immediate issue with bad colors was resolved by using cut 1-4, which pushes my current main use case colors into more suitable territory (darker text on light bg).

http://www.frexx.de/xterm-256-notes/ has part of an xterm2rgb function whose concept could possibly be of use here. if we draw a diagonal line through the palette (read also http://particletree.com/notebook/calculating-color-contrast-for-legible-text/), there are certain hex patterns that will then just need to be reversed for light vs dark.

but to detect between light and dark, i see no other way than for the user to take care of it by using a COLORFGBG-compatible terminal or taking care of this whole PS1 shebang in personal .bashrc.

on a system bashrc level where you would need to already know COLORFGBG when you do anything in /etc/bash/bashrc, only way is to probably forward that variable within .ssh/config. if it doesn't exist, then a comprehensive system wide solution for this doesn't seem possible at the time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment