Production is Red, Development is Blue | Hacker News Reader

Production is Red, Development is Blue

jeffmiller.github.com

173 pointsfukumoto48 comments

To get a red prompt drop this line in your ~/.bashrc file on your production server:

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.

To avoid cryptic looking escape sequences, one could have the colour codes named in their .?shrc file [1]:

  txtblk='\e[0;30m' # Black - Regular
  txtred='\e[0;31m' # Red
  txtgrn='\e[0;32m' # Green
  txtylw='\e[0;33m' # Yellow
  txtblu='\e[0;34m' # Blue
  txtpur='\e[0;35m' # Purple
  txtcyn='\e[0;36m' # Cyan
  txtwht='\e[0;37m' # White
  bldblk='\e[1;30m' # Black - Bold
  bldred='\e[1;31m' # Red
  bldgrn='\e[1;32m' # Green
  bldylw='\e[1;33m' # Yellow
  bldblu='\e[1;34m' # Blue
  bldpur='\e[1;35m' # Purple
  bldcyn='\e[1;36m' # Cyan
  bldwht='\e[1;37m' # White
  unkblk='\e[4;30m' # Black - Underline
  undred='\e[4;31m' # Red
  undgrn='\e[4;32m' # Green
  undylw='\e[4;33m' # Yellow
  undblu='\e[4;34m' # Blue
  undpur='\e[4;35m' # Purple
  undcyn='\e[4;36m' # Cyan
  undwht='\e[4;37m' # White
  bakblk='\e[40m'   # Black - Background
  bakred='\e[41m'   # Red
  badgrn='\e[42m'   # Green
  bakylw='\e[43m'   # Yellow
  bakblu='\e[44m'   # Blue
  bakpur='\e[45m'   # Purple
  bakcyn='\e[46m'   # Cyan
  bakwht='\e[47m'   # White
  txtrst='\e[0m'    # Text Reset

[1] https://wiki.archlinux.org/index.php/Color_Bash_Prompt

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 do that in bash for root/non-root users (root is red, non-root is blue):

    if [[ ${EUID} == 0 ]] ; then
        PS1='\[\033[01m\][ \[\033[01;31m\]\u@\h \[\033[00m\]\[\033[01m\]] \[\033[01;32m\]\w\[\033[00m\]\n\[\033[01;31m\]\$\[\033[00m\]> '
    else
        PS1='\[\033[01m\][ \[\033[01;34m\]\u@\h \[\033[00m\]\[\033[01m\]] \[\033[01;32m\]\w\[\033[00m\]\n\[\033[01;34m\]\$\[\033[00m\]> '
    fi

Interesting to think about using it across servers, though.

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).

Konsole does this automatically, at least on openSuSE linux.

It's actually just the default bash config on openSUSE, nothing to do with Konsole. It works on text-mode VTs, via ssh, etc.

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)).

You could put a shell script around cd that checks the current working directory every time you cd and alerts you appropriately.

A little clunky, I'll admit. I'd like to hear any more graceful solutions.

From man bash, the variable PROMPT_COMMAND:

  If set, the value is executed as a command prior to issuing each primary prompt.

e.g.:

  PROMPT_COMMAND='[[ "$PWD" =~ ^/sensitive/area ]] && PS1="be careful: " || PS1="normalprompt: "'

Pro tip: In Terminal.app you need the checkbox "Display ANSI colors" checked.

I prefer:

PS1="\[\e[1;31m\]$PS1\[\e[0m\]"

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.

Oh please yes. + a bucket load for code.google.com which comes up a lot and would provide nice glanceable info.

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.

Let's just call it me being way over tired. Definitely not an easy mistake to make.

I agree. foo.github.com and github.com/foo are the important domain considerations.

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

fab is fabric, a very very nice deployment tool in Python: http://www.fabfile.org

Never say never. I've done development on production machines, sometimes even when logged in as root ;)

But I agree with the sentiment - think very hard before doing this, and don't make it a habit.

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.

Or for those less python-happy: just use expect

http://en.wikipedia.org/wiki/Expect

Slightly weird syntax, but learnable in a few hours. You are likely to already have it on your machines.

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.

Production is red for me too. Like this: http://img.ly/images/663862/full

I do this by setting the Window Background Color in saved sessions in PuTTY. Works great! (The different colors for different machines, I mean).

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 :-)

Colorful shell prompts can be used for the same purpose.

except when you're doing something like editing a file, tailing a log, or doing anything other than staring at a command prompt.

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.

One of the developers of iTerm2 also liked the idea responded to my tweet by opening an issue request for it:

http://code.google.com/p/iterm2/issues/detail?id=454

Wow, pretty cool! As an iTerm user I'll be looking forward to that.

Here's the same for those of us on Macs and who like transparent Terminals.

http://geek.swombat.com/setting-up-terminalapp-with-tr-0

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.

Any chance it is possible to accomplish on Ubuntu?

you could use something like xtermcontrol (http://www.thrysoee.dk/xtermcontrol/) and run it from your ~/.ssh/config file per-host:

     Host someproductionbox
          LocalCommand xtermcontrol --bg=red
     
     Host sometestbox
          LocalCommand xtermcontrol --bg=blue

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:

    dbus-send --session /net/sf/roxterm/Options net.sf.roxterm.Options.SetColourScheme string:$ROXTERM_ID "string:NAME_OF_COLOR_SCHEME"

Edit your .bashrc in your home directory.

Uncomment 'force_color_prompt=yes' Edit the line following if color_prompt is yes. By default it's green (1;32m). Red is 0;31m.

Make sure to make a copy of the .bashrc file before starting.

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.

I have this set in my .bashrc:

     function settitle {
         echo -en "\e]0; $* \a"
     }
     
     function ssh {
         settitle ssh $*
         echo     /usr/bin/ssh $*
         /usr/bin/ssh $*
     }
     function sftp {
         settitle sftp $*
         echo     /usr/bin/ssh $*
         /usr/bin/sftp $*
     }

No, it's not bright and colorful, but it does a good job of telling me where the gnome-terminal I'm using is connected to.

This doesn't work with GNU Screen.

Debugging is sweet,

And so are you.

Reply on news.ycombinator.com