Setting Environment Variables in Ubuntu

Ubuntu environment variables

Stumped on how to set environment variables in Ubuntu? Follow along as I walk you through how to set this up properly with less hassle.

Per User Setting: .bashrc is Your Friend

As you install new software, there will be times when you need to set environment variables for applications. Often times, this has to do with setting paths. To make these variables stick whenever you go into and out of a Bash shell, you can place them into .bashrc. This file is located in your home directory and is hidden.

Before you modify .bashrc with your GUI text editor, you need to be running as root. Install gksudo (if needed) which gives GUI applications root level access:

sudo apt-get install gksu

I use Geany IDE for basic text editing. Go get that too (you’ll love it):

sudo apt-get install geany

To edit .bashrc in my home folder with Geany:

cd /home/kkobashi
gksu geany .bashrc

Similar to an autoexec.bat file in DOS/Windows, you can run script commands from within .bashrc. After your terminal loads, .bashrc is executed automatically.

In the example below, I have several applications that need their paths set. Some have version information as part of the path. The best thing to do in this case is breakup the version info into separate environment variables and then reference them at appropriate places in the script. Other scripts can reference these environment variables (as shown in below).

By doing so, whenever I upgrade my software, I can quickly change the version info in one place.

  2. #The purpose is to control your run environment in one location
  3. #Very important if you are a software developer or QA engineer
  5. #Setup default text editor
  6. export EDITOR=/bin/nano
  8. #Set all version information as environment variables here
  9. export IDEAVERSION=139.1117.1
  10. export JDKVERSION=1.8.0_31
  12. #Set up all your paths here
  13. #Java
  14. export JAVA_HOME=$HOME/Java/jdk${JDKVERSION}
  16. #Go programming language
  17. export GOROOT=$HOME/go
  18. export GOPATH=$HOME/Workspace/Go
  20. #Global system path
  21. export PATH=$PATH:$GOROOT/bin:$GOPATH/bin:JAVA_HOME/bin

  1. #!/bin/bash
  3. #Place all scripts in your home Scripts directory
  4. #IntelliJ IDE
  5. #Reference the environment variable IDEAVERSION
  6. cd $HOME/IntelliJ/idea-IU-${IDEAVERSION}/bin
  7. ./

For the purpose of this discussion, my home layout looks like this. I’ve gotten into the habit of placing everything under my home folder to organize and remember what I installed. This way I know where everything is and can update, and remove apps without having to hunt for them on disk.


Everytime I boot Ubuntu, my environment will be set up properly. If I have to upgrade software, I simply change the environment variables in one place, .bashrc, and they will point to the proper locations.

This I find is the best way to control my run environment and navigate quickly around it too. I’d rather type:


Than this:

cd /home/kkobashi/Workspace/Go

System Wide Environment Settings

The discussion above surrounded itself with setting environment variables for a particular user in /home/username/.bashrc. What if you wanted all users to have these environment settings?

You can do this through the /etc/environment file. Here, you can list one line per variable an assignment statement.


The problem with this approach is that it is not very flexible. You cannot do variable substitution. So in the case where I would like to keep track of the version and path to a particular piece of software, you can’t use this approach.

Some people will say to modify the /etc/profile file. I would not do this because this is more of a configuration file that can be modified by other software installers. Monkeying around with this directly can result in application problems so I avoid it.

Under Ubuntu, if you take a look inside /etc/profile you will see that if a /etc/profile.d directory exists, each shell file (*.sh) in the directory gets executed:

  1. # /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
  2. # and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).
  4. if [ "$PS1" ]; then
  5.   if [ "$BASH" ] && [ "$BASH" != "/bin/sh" ]; then
  6.     # The file bash.bashrc already sets the default PS1.
  7.     # PS1='\h:\w\$ '
  8.     if [ -f /etc/bash.bashrc ]; then
  9.       . /etc/bash.bashrc
  10.     fi
  11.   else
  12.     if [ "`id -u`" -eq 0 ]; then
  13.       PS1='# '
  14.     else
  15.       PS1='$ '
  16.     fi
  17.   fi
  18. fi
  20. # The default umask is now handled by pam_umask.
  21. # See pam_umask(8) and /etc/login.defs.
  23. if [ -d /etc/profile.d ]; then
  24.   for i in /etc/profile.d/*.sh; do
  25.     if [ -r $i ]; then
  26.       . $i
  27.     fi
  28.   done
  29.   unset i
  30. fi

So what do you do knowing this? You just add your own shell file to be automatically executed. Note something very important that is skipped by most references – the execution of the shell script is iterated over based upon filename sorting! So if you want to guarantee some other script doesn’t overtake your settings, create a filename by the name of say, so it is executed last.

This is a better place to put in your system wide environment variables and variable substitution scripts.

Taking the examples above:

  1. /etc/profile.d/
  3. #Setup default text editor
  4. export EDITOR=/bin/nano
  6. export IDEAVERSION=139.1117.1
  7. export JDKVERSION=1.8.0_31
  9. #Set up all your paths here
  10. #Java
  11. export JAVA_HOME=$HOME/Java/jdk${JDKVERSION}
  13. #Go programming language
  14. export GOROOT=$HOME/go
  15. export GOPATH=$HOME/Workspace/Go
  17. #Global system path
  18. export PATH=$PATH:$GOROOT/bin:$GOPATH/bin:JAVA_HOME/bin

Any process can override existing environment settings. For example, applications can have configuration files that are executed in script to override existing environment variable settings. An example of this is the hBase platform where a configuration file ( is executed prior to running hBase. So always check your environment after installing new software.


Of Interest