Right, let’s talk about /etc/environment. This is the system’s blunt instrument for setting environment variables. It’s not a script; it’s a simple, key-value pair file that gets read by every single login process on the box. Think of it as the global, mandatory bulletin board for the entire operating system. If you need a variable—like a critical path or a license server address—to be set for every user, from the grizzled sysadmin to the freshly created www-data user, this is your place.

But here’s the first thing you need to get straight, and it’s a biggie: this file is not parsed by the shell. No bash, no zsh, no fish. This is crucial. It’s read directly by pam_env, the Pluggable Authentication Module responsible for environment handling during the login process. This means all the cool shell tricks you know? They’re useless here.

What It Looks Like (And What It Can’t Do)

Open it up. On a standard Ubuntu or Debian system, it’s probably almost empty. The syntax is dead simple:

VARIABLE_NAME=value
ANOTHER_VARIABLE="a value with spaces"

That’s it. No export, no $ signs for variable expansion, no command substitution using backticks or $(). If you try to do something clever like JAVA_HOME=$(which java), you’re going to have a bad time. The $(which java) part will be treated as a literal string. The user nobody will log in and find their JAVA_HOME set to the text string “$(which java)”, which is hilarious until you get the pager alert at 3 a.m.

This is its greatest strength and its most frustrating limitation. It’s robust and predictable because it’s simple, but it’s also inflexible.

The Critical Pitfall: No Variable Expansion

This is the number one way people screw this up. Let’s say you want to add a new directory to the global PATH. Your first instinct might be to write:

PATH=/my/cool/new/bin:$PATH

Don’t. Just don’t. Remember, no shell parsing. The :$PATH part is, again, a literal string. Your PATH will now end with the four characters “:$PATH”, which will break everything in spectacularly confusing ways. The correct, albeit more cumbersome, way is to use the pam_env syntax for expanding existing variables:

PATH=/my/cool/new/bin:${PATH}

Notice the braces? That’s the pam_env syntax. It knows how to expand a few specific variables, and PATH is one of them. But you can’t just use any variable here; it’s generally limited to ones that are already set in the very early stages of the system’s login process. Relying on this for your own custom variables is a path to madness. For appending to PATH system-wide, the /etc/profile.d/ directory is often a safer and more flexible bet.

When To Use It (And When To Run Away)

So, when does this blunt tool become the right one?

Use /etc/environment for:

  • Static, absolute paths: Setting JAVA_HOME, CATALINA_HOME, or the path to a license file server.
  • Simple key-value pairs: COMPANY_NAME="Acme Corp", APP_ENV=production.
  • Truly global settings: A variable that must be available to all users and services that start via a login shell.

Avoid /etc/environment for:

  • Anything that requires logic, conditionals, or command execution.
  • Anything that depends on the value of another custom variable.
  • Modifying PATH unless you’re absolutely sure of the syntax and you understand that every user must have this path.

Making Your Changes Stick

You edited the file. Now what? The changes won’t magically appear in your current shell session. They are loaded at user login. The easiest way to see your handiwork is to just log out and log back in. Or, open a new login shell from your current terminal:

su - $USER

This command effectively simulates a fresh login for your user, and you should see your new variables. You can check with printenv VARIABLE_NAME.

One final piece of advice: back up this file before you touch it. A syntax error here won’t crash your system, but it can prevent anyone from logging in correctly, which is arguably worse. You’d have to boot into a recovery shell to fix it. So, edit it with the respect a file this powerful deserves. It’s not where you go to be clever; it’s where you go to be definitive.