{"id":1437,"date":"2014-03-02T21:17:52","date_gmt":"2014-03-03T02:17:52","guid":{"rendered":"http:\/\/www.dannyadam.com\/blog\/?p=1437"},"modified":"2018-09-13T15:09:12","modified_gmt":"2018-09-13T20:09:12","slug":"color-coded-bash-prompt","status":"publish","type":"post","link":"https:\/\/www.dannyadam.com\/blog\/2014\/03\/color-coded-bash-prompt\/","title":{"rendered":"Color Coded Bash Prompt"},"content":{"rendered":"

This post explains what I’m referring to by\u00a0color coded bash prompt<\/em>, why it is useful to have one, and presents an implementation.<\/p>\n

By color coded bash prompt<\/em>, I am referring to the use of colors to represent aspects of the environment running bash. An ordinary bash prompt may display a username and hostname. Color coding can be used to represent whether the user is root, whether the session is running on a local or remote machine, and other aspects of the environment (not covered in this post).<\/p>\n

When running multiple terminals at the same time, with some connected to remote machines and\/or running as root, color coding makes it easier to keep track of the sessions, and may help prevent inadvertently entering a command as root or on the wrong machine.<\/p>\n

I have configured my bash prompt’s colors to be a function of whether I am running as a root or non-root user, and whether I am connected to a local or remote machine. The username is displayed in green for a non-root user and in red for the root user. The hostname is displayed in blue for a local bash session and in cyan for a remote session.<\/p>\n

The following image shows the four possible scenarios, 1) on a local machine as a non-root user, 2) on a local machine as root, 3) on a remote machine as a non-root user, and 4) on a remote machine as root.<\/p>\n

\"bash\"<\/a><\/p>\n

Color coding can be added by putting the following snippet of code in your non-root user’s .bashrc, both locally and on remote machines. In the session shown in the image above, sudo -s<\/em> was used to become root. Using sudo su<\/em> would not have worked unless the code was also added to root’s .bashrc or to a global bashrc. By switching to root with\u00a0sudo -s<\/em> or sudo bash<\/em> instead of sudo su<\/em>, root’s shell will contain the environment provided by the user’s .bashrc.<\/p>\n

Some of the functions for determining whether the current shell is running in an ssh session are from a\u00a0response<\/a>\u00a0on Unix Stack Exchange. I could not figure out a way to reliably determine whether the running shell is in an ssh session when the shell is running within xterm, so in that case the hostname is displayed in the default color.<\/p>\n