Run Command as a Login Shell ? Why? And why not?

If you’ve ever configured Tilix, GNOME Terminal, Konsole, or another Linux terminal emulator, you’ve probably seen the mysterious checkbox:

Run command as a login shell

Most Linux users simply ignore it. Others tick it because “it fixes something.” But why does this option even exist?

The answer lies in the history of Unix, and it actually makes perfect sense once you understand where it came from.

---

The World Before Graphical Desktops

To understand login shells, we have to go back to the 1970s.

There were no graphical desktops. No GNOME, KDE, or terminal emulators.

You sat in front of a physical terminal connected to a Unix computer, often over a serial cable.

The process looked like this:

Serial Terminal
      │
      ▼
   login program
      │
      ▼
      sh

The login program authenticated your username and password.

Once authentication succeeded, it started your shell.

That shell knew it had been started by the login program, so it treated itself as a login shell.

---

A Login Shell Had One Job

The shell wasn’t just there to interpret commands.

It was responsible for setting up your entire Unix session.

Typical tasks included:

• Setting your PATH
• Configuring locale variables
• Setting TERM
• Initialising your mail environment
• Running stty
• Starting background agents
• Changing to your home directory

These are things that only need to happen once when you begin working.

---

What Happens When You Start Another Shell?

Suppose you already have a shell running and type:

bash

The process tree now looks like this:

login
  └── bash    ← login shell
        └── bash
             └── bash

The child shells automatically inherit the environment from their parent.

There is no need to rebuild it from scratch.

If every shell reran all the startup scripts, bad things could happen:

• Duplicate background daemons
• Multiple ssh-agent instances
• Repeated network mounts
• Slower shell startup

So Unix distinguished between two kinds of shell.

---

Two Different Startup Phases

A shell can be started in one of two important ways.

Login shell

Runs once at the beginning of a session.

Typical Bash startup files:

~/.bash_profile
~/.bash_login
~/.profile

(Bash uses the first one it finds.)

Interactive non-login shell

Runs every time you open another shell.

Typically reads:

~/.bashrc

This is where things like aliases, prompts, shell completion and functions belong.

---

Then Graphical Desktops Arrived

Fast-forward to today.

When you open Tilix or GNOME Terminal, something very different happens.

There is no login program involved.

The terminal emulator simply starts a shell:

GNOME Terminal
      │
      ▼
     bash

Now we have a philosophical question.

Is opening a terminal window the start of a new login session?

Historically, the answer was no.

You’re already logged into your desktop.

But many users expected their terminal to behave exactly like logging in, because that’s where their environment variables were configured.

Different terminal emulators made different choices.

Eventually, most simply exposed the choice as an option:

Run command as a login shell

---

Why Not Always Use Login Shells?

Because login scripts were never intended to run repeatedly.

Imagine your .profile contains:

eval "$(ssh-agent)"

Opening five terminal windows would create five separate SSH agents.

Or perhaps it contains:

mount ~/network-drive

Now every terminal tries to mount the same filesystem.

Or:

start-my-daemon

Now you’ve accidentally started the same daemon ten times.

These are session-level tasks.

They should happen once.

By contrast, things like this belong in .bashrc:

alias ll='ls -alF'

PS1='\u@\h:\w\$ '

source /usr/share/bash-completion/bash_completion

These settings are useful in every interactive shell.

---

Why Ubuntu Seems to Ignore the Difference

Modern Linux distributions try to hide this complexity.

Ubuntu’s default .profile contains something similar to:

if [ -n "$BASH_VERSION" ]; then
    . ~/.bashrc
fi

So a login shell loads both:

.profile
    │
    └── .bashrc

This means users usually get the same aliases, prompt and shell functions regardless of whether the shell is a login shell.

It’s a practical compromise that reduces confusion while remaining compatible with the historical Unix design.

---

So What Does the Tilix Checkbox Actually Do?

When enabled, Tilix starts your shell as if it had been launched by the Unix login program.

For Bash, it’s roughly equivalent to:

bash -l -c "your-command"

instead of:

bash -c "your-command"

The -l tells Bash:

“Pretend you’ve just logged in.”

As a result, Bash reads your login startup files before executing the command.

---

The Design Isn’t Weird—It’s Historical

At first glance, the distinction between login and non-login shells feels like an unnecessary complication.

In reality, it reflects a very clean separation of responsibilities:

• Login startup configures the user session.
• Interactive startup configures each shell.

This made perfect sense on multi-user Unix systems with serial terminals, and the same behaviour has been preserved for decades because millions of scripts, system configurations and user environments still depend on it.

The “Run command as a login shell” checkbox in modern terminal emulators isn’t there because Linux is quirky. It’s there because today’s graphical terminals are standing on top of fifty years of Unix history.