I'm trying to understand non-interactive & non-login shells and having a hard time conceptualize the process a non-interactive & non-login shell goes through to start up.

The way I understand things is when a script or a process is started: a region of memory is created and the child process replicates a duplicate environment of the parent by being forked -- which makes sense to me.

What's confusing me is when is the shell environment defined for a non-interactive non-login process or script? When I think about how an interactive shell is started I get a little lost.

The way I understand an interactive shell is:

  1. User passes login ID to Linux kernel
  2. Linux kernel looks the user up in the /etc/password file and identifies the assigned shell
  3. the shell is started
  4. the shell reads the login scripts to define the shell environment for the user
  5. Linux produces a command prompt to indicate the shell is ready to accept commands

Is the process for a non-interactive & non-login shell similar? This is how I envision it working:

  1. The process is forked by the parent process
  2. Linux identifies the user ID the process will runs as
  3. Linux looks the user id up in the /etc/password file
  4. the shell is started
  5. the BASH_ENV is read (If it was defined)
  6. the process interacts with the shell to pass commands to the API

For some reason this seems clunky and like I'm missing something. Could someone let me know if I'm on the right path please?

  • Relating an excellent question: unix.stackexchange.com/q/339506/117549
    – Jeff Schaller
    Commented Nov 16, 2017 at 18:18
  • The most typical use case for a non-interactive shell is a shell invoked to run a script, either explicitly (e.g., bash script) or implicitly (using a #! line at the beginning of the script). Also, shells which are invoked with -c (bash -c command) or with the input coming from a file or pipe ( ... | bash, bash < file) are non-interactive shells. The vast majority of non-interactive shells are also non-login shells. A login shell is simply any shell started with the option -l or with the zeroth command line argument beginning with a dash; that's how /bin/login does it.
    – AlexP
    Commented Nov 16, 2017 at 19:54

1 Answer 1


You don't really need to think about the passwd file. The shell doesn't generally handle password authentication. It's probably a little simpler than you think. Other programs, such as init, getty and login actually perform most of the login process that you've described in your question.

Most shells consider the session as an interactive shell if the shell is started with the -i option, or if the standard output is connected to a terminal device (for example, /dev/tty01).

The shell considers the session as a login shell if the first character of argument zero ($0) is a dash (-). Some shells also support a -l option to cause the same effect.

The "login shell" is usually and traditionally started this way via the conventional Linux Login Process:

The init or other program starts a getty process on each terminal which can be used for login.

The getty program prints a prompt and reads the username from the terminal. Then getty calls the login program with the username as the argument.

The login program looks up the username in the passwd file, reads and authenticates the password from the user, sets up the user and group IDs of the user and the environment variables, and performs other login related tasks before starting the login shell.

The login process notifies the shell that it's a login shell by prepending a dash (-) to the program name in argv[0] (also known as $0 within the shell).

For more specifics about the concept of login and interactive sessions, you may want to consult the man page for getty, login and for the specific shell that you're using. Different shells (eg, sh, ksh, bash, etc) have slightly different ways of reading startup command files (such as .profile, .bash_rc, etc.)

  • Thank you for the reply! After giving things a bit of thought I think what confuses me specifically is how a background process interacts with a shell... And when a shell environment associated with a process user ID is defined. For example the user oracle for an Oracle database is assigned /bin/bash as it's shell in Linux. Would that oracle background processes use a shell to pass commands to the API?
    – Bodisha
    Commented Nov 16, 2017 at 19:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .