I have a similar section in my .bashrc via a somewhat hackish loop (or two):
ESC=$'\x1b'
# Terminal color escapes
colornames=(BLACK RED GREEN YELLOW BLUE MAGENTA CYAN)
for i in ${!colornames[@]}; do
eval "${colornames[$i]}=\"${ESC}[3${i}m\""
eval "BG${colornames[$i]}=\"${ESC}[4${i}m\""
done
# There are holes in this sequence, so it doesn't loop nicely
BOLD="${ESC}[1m"
DARK="${ESC}[2m"
UNDERLINE="${ESC}[4m"
BLINK="${ESC}[5m"
INVERSE="${ESC}[7m"
RST="${ESC}[m"
styles=(BOLD DARK UNDERLINE BLINK INVERSE RST)
# and the PS1-safe versions of the above
for i in ${colornames[@]} ${colornames[@]/#/BG} ${styles[@]}; do
eval "PS$i=\"\\[\$$i\\]\""
done
Having color escapes in shell variables comes in handy from time to time (like faking 'colordiff' with sed).
I used to have a different prompt color when SSH_CONNECTION was in my environment, to distinguish local terminals from remote connections. And also root/non-root, although I didn't know about $EUID and used the less-effective $(id -u).
I do exactly this as well as add a little blurb in motd saysing that this machine is production, tread carefully. This seems to solve a great deal of mistaken identity problems.
Is there any way to set this on directory level? I do my development in my /home/XYZ folder, and production is in /usr/local/www/XYZ and it would be great if I could set the background to red in the production dir (if I happen to wander into it somehow (which I really almost never do)).
I think it is time to add *.github.com to the filter list. I read through the whole post before I realized it was not from GitHub, but someone who hosts on github. We do it for blogger etc, can we get github added?
it should probably just try to strip ^www\d*?\. from the domain and leave everything else, rather than strip off the first component of the hostname regardless of what it is.
better to print too long a url for some than too short for things like example.github.com, code.google.com, etc.
I was thinking that maybe Github had established a new color-coding scheme for differentiating projects that are production-ready from ones that aren't. That would have been interesting.
Agree with the request and hence upvoted, however not quite sure how you didn't realise it wasn't officially from GitHub as soon as you loaded the page.
I posted this to the feature requests a long time ago. I don't know how much pg and the other maintainers actually look at the feature requests (especially given that the same request for google.com, which seems like a nobrainer, has been near the top for >a year), but it's worth a try: http://news.ycombinator.com/item?id=1239752
You should never ssh into a production system, everything should be going through automated scripts. Doing this will really save your life. For me this means:
$ fab deploy
... oups errors on the website even if tested on stagging ...
$ fab getdebuglog
$ fab rollback
... fix test ...
$ fab deploy
I make a lot of mistakes, but at least when I do them by hand I know who to blame. Saying that people "should never" log into a production system is a tad dogmatic.
I've built *Nix testing frameworks using Expect. Would one use Expect/Fabric/etc. to manage deployments and development environments?
Having the ability to immediately stage an environment to reproduce an error without configuration issues would really take a lot of treachery out of trying to evolve larger systems.
I've seen it used to manage deployments, and it's not perfect, but it's a lot better than expecting a whole team of engineers to muck about on the production servers and remember to get everything just right.
In fact, an expect script [can be] nicely self-documenting, because somebody can look at it and see "oh these are the steps to deploy X" because the scripts basically read as "at the foo prompt, enter bar" over and over again, with some branching to handle varying responses (missing prereq, error messages).
The "ultimate" in building environments would probably have to be something more comprehensive and declarative like bcfg (http://trac.mcs.anl.gov/projects/bcfg2) which I have seen in action and it works but is very XML-heavy.
We do this in a different context for our webapp work. We have three primary environments: development, staging and production. We code a contextual, 20px high, colored div at the top of our master template. It's red for development, yellow for staging, and doesn't exist in production (i know it seems backwards, but you can't really show an extra red bar in production :p ). It also somewhere we dump out some quick and dirty debug info.
I've been burned too many times when jumping back and forth between production and dev browser tabs. This simple hack saves me time, and possibly some headaches.
Did this at one place I worked for terminals and sql windows (red = prod, green = dev, yellow = test). It does tend to inform you coworkers if they should really be asking you stuff when you have a whole screen of red.
Doing the same thing for the webapp is also useful--it serves as visual reminder to QA folk that the production box (white background) is /not/ someplace they should be running test scenarios (vs. the QA box with an orange/whatever background).
Also, you can use different colors for different QA boxes--"I need blue qa deployed" or "That fix is in black qa".
(Yes, this was an enterprise environment, why do you ask?)
I now run Byobu on my servers -- it's made my sysadmin life substantially better -- and for each server I pick a different color for the status bar along the bottom.
I like this idea, and used to have a whole spectrum of color-coded terminals when I looked after dozens of boxes years ago at a large company. It proved to be very useful because although we did automate most activity on the machines (using cfengine + other tools) I still found myself logging in regularly to various machines and could often have many terminals on screen.
However... the color coding can be a bit misleading sometimes, particularly if you are chaining SSH sessions and the colors are being set on terminal launch (not on shell login). I was using PuTTY config settings for color on my company-mandated Windows machine and soon found the limitations of this when I logged in to machine A (green), then from there to machine B (red). The terminal was still green and some time later I trusted the color and ran a (destructive) command in the wrong shell. This reinforced to me that while useful, color is no substitute for thinking before typing, and double checking everything before performing destructive operations :-)
FWIW, my editor has its own background color (vim in 256 color mode), so I wouldn't see the terminal background either way.
However, I like the idea in general, just not the implementation. It would be nice if modern terminal emulators (hello iTerm!) could adopt new escape sequences to do things like set a background color on the tab (like ZOC and some others support by client-side configuration).
There is still lots of room for innovation in the terminal, it's a bit sad to see progress at such a glacial pace. I'd actually pay for a terminal emulator that's fast (first priority) and then also makes my life easier with innovative features like the above.
For some reason all innovation in the terminal space seems to have died when dialup BBS went out of fashion 10 years ago. Most terminal emulators have even moved backwards and don't support ZModem anymore, which could be very useful to provide adhoc drag'n'drop uploads instead of the scp/rsync limbo that is so common nowadays.
I just set up the command line colors to be different on production vs. development machines - I like my terminal backgrounds black, and regular text white.
Great tip! Note that for this to work, you need to edit /etc/ssh/ssh_config and set
PermitLocalCommand yes
There's no way to change profile from the command line using gnome-terminal, unfortunately, but there is "roxterm" which is very similar in functionality and lets you do the following to change the color scheme of the current terminal window:
The way I prefer to do it in gnome-terminal and konsole (both can do it) is to set up sessions that have the color info in the session for the terminal, and the command to start the session is an ssh command. In konsole, theoretically, you can bind this to a keystroke but there is a long-standing issue with that where it can't seem to persist across restarts, and has weird problems sticking even within a session. But when it works it's convenient, especially when combined with SSH's ControlMaster.
PS1='\[\e[1;31m\][\u@\h \W]\$\[\e[0m\] '
We use this in our production environments and the red prompt, though not as jarring as a red background, is still scary enough to serve its purpose.
One upside in setting this up on the server, as opposed to local like the OP, is that all connections in will get the red prompt.