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:
- User passes login ID to Linux kernel
- Linux kernel looks the user up in the /etc/password file and identifies the assigned shell
- the shell is started
- the shell reads the login scripts to define the shell environment for the user
- 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:
- The process is forked by the parent process
- Linux identifies the user ID the process will runs as
- Linux looks the user id up in the /etc/password file
- the shell is started
- the BASH_ENV is read (If it was defined)
- 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?
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.