 
Learn through the super-clean Baeldung Pro experience:
>> Membership and Baeldung Pro.
No ads, dark-mode and 6 months free of IntelliJ Idea Ultimate to start with.
Last updated: May 23, 2025
When we work in Unix-like systems, we often encounter environment variables like $USER and $USERNAME. These variables hold our current username.
In this tutorial, we’ll explore which process sets the $USER and $USERNAME environment variables. First, we’ll cover what these environment variables are. Next, we’ll discuss the process that sets them. Lastly, we’ll look at the whoami command and its use in relation to these environment variables.
In Unix-like systems, environment variables are dynamic values that the shell and other programs use to determine information like user preferences, system settings, and session context. We access these variables using the $ symbol, like $HOME, $PATH, or $USER.
In addition, let’s look at the meaning of $USER and $USERNAME:
A Linux system stores all these environment variables in key-value pairs to manage session-specific information for processes.
On most Linux systems, especially Debian-based ones like Ubuntu, the $USER variable is set automatically by the login process. More specifically, the login shell or a startup file like /etc/profile, ~/.bash_profile, or ~/.bashrc initializes the environment variables such as $USER or $USERNAME.
To understand where exactly variables like $USER come from, we need to look at the login process itself. The login utility is the very first program we interact with when we log into a Unix-like system, either via a terminal or a graphical login manager. It’s responsible for authenticating the user and setting up their session environment, including many key environment variables.
The login process sets the values for $HOME, $USER, $SHELL, $PATH, $LOGNAME, and $MAIL according to the appropriate fields in the password entry. Furthermore, the login utility enters information into the environment specifying the user’s home directory, command interpreter, search path, terminal type, and user name.
For instance, if we open a terminal and run the command echo $USER, we get the username:
$ echo $USER
sidrahThat tells us the current user is sidrah. However, the key point here is that since the shell session initialized it that way, this information was stored in $USER.
Moreover, in Debian and Ubuntu systems using bash, the login program usually sets and passes on the value of $USER. This means when we log in via a terminal or graphical session, the system looks up our user details and sets $USER accordingly.
With the $USERNAME variable, things get a bit trickier. $USERNAME isn’t as universally supported or set as $USER.
On some systems, especially those influenced by Windows or environments using the csh or tcsh shells, $USERNAME might be set. However, in many Linux distributions and shell environments, $USERNAME is either unset or only set manually in user-specific startup files.
Let’s test it:
$ echo $USERNAME
We might see a blank line. But if we manually set it using the export command, we get our username:
$ export USERNAME=$USERSo, while $USER is almost always set by default on Linux, $USERNAME is more variable and system-dependent.
While $USER is commonly set in most Linux environments, it’s still better not to rely solely on it in portable scripts. $USERNAME, on the other hand, is even less predictable. If we’re writing shell scripts that need to work across different Unix-like systems, e.g., Linux, macOS, and BSD, it’s safer to use commands like whoami or id -un.
For instance, let’s look at the difference in the output of whoami and id:
$ whoami
sidrahThis command always returns the currently effective user name. It doesn’t rely on whether the system correctly sets an environment variable. However, if we run the id -u command, we see an integer number:
$ id -u
501The command serves a similar purpose to whoami, but returns the numeric user ID instead of the username, making it slightly more script-friendly for structured output.
Subsequently, this raises the question: why use the whoami command instead of the $USER and $USERNAME variables? To answer this, let’s look at some shell script examples:
$ cat user.sh
#!/bin/bash
echo "Hello, $USER!"Let’s grant the user.sh script execute permissions and run it:
$ chmod u+x user.sh
$ ./user.sh
Hello, sidrah!This works great if $USER is set. But imagine a situation where the system process runs the script, or the script runs under a restricted shell, and $USER isn’t set. The script wouldn’t print the username:
$ ./user.sh
Hello, !So, this isn’t very helpful.
On the other hand, using whoami guarantees reliability:
$ cat whoami.sh
#!/bin/bash
echo "Hello, $(whoami)!"Let’s grant execute permissions and run the script:
$ chmod u+x whoami.sh
$ ./whoami.sh
Hello, sidrah!Now, we’ll always get the correct username, even if $USER or $USERNAME are unset.
Another reason to use whoami is security. Users or scripts can modify the environment variables. So, if we’re writing a security-sensitive script or performing file ownership checks, we don’t want to rely on variables that might have been tampered with.
Let’s look at a security-flawed example:
$ cat security.sh
if [ "$USER" == "admin" ]; then
    echo "Access granted"
fiWe can change the $USER value using the export command:
$ export USER=adminThis can trick the script into thinking that the user is admin.
A better approach would be to use the whoami or id command:
$ cat idCommand.sh
if [ "$(id -un)" == "admin" ]; then
    echo "Access granted"
fiThis checks for the real username — not just the value of a variable.
To check whether the system has set the value for $USER, we can use the -z flag:
$ cat usernameCheck.sh
if [ -z "$USER" ]; then
    echo "USER is not set"
else
    echo "USER is $USER"
fiSimilarly, we can check for $USERNAME this way. Moreover, if we want to be sure we have a username no matter what, we can write a condition that runs the whoami command if $USER doesn’t exist.
$ CURRENT_USER=${USER:-$(whoami)}
$ echo "Current user: $CURRENT_USER"This way, if the $USER variable already has a value, we use it. Otherwise, we run the whoami command.
In this article, we discussed which process sets the $USER and $USERNAME variables. In most environments, $USER or $LOGNAME reliably indicates the current user, but they shouldn’t be trusted blindly. So, when writing robust shell scripts or user-aware applications, it’s important to understand the limitations of relying on environment variables.
For scripts, id -un and whoami offer more consistent results across platforms and user sessions. However, if we must rely on environment variables, fallback patterns like ${USER:-${USERNAME:-${LOGNAME}}} can help us avoid surprises.