How to make sense of non-interactive login shell?

Question

A non-interactive non-login shell is easy to understand, simply executing a shell script in Terminal will launched a non-interactive non-login shell that will run this shell script.

But I don't understand how non-interactive login shell works, if the shell is non-interactive, then you can't enter your login credentials when the shell is executed, so do you put your login credentials in the shell script or something?

Answer 1

I can remember this confusion of my own the first time I started digging into the internals of a UNIX system. This is a much simplified explanation; understanding modern systems requires a lot of background knowledge that is too wide to fit into a StackExchange answer like this one.

The login credentials are requested by a privileged process called login and you can see the executable with ls -l /bin/login. (Source is also available, of course.) More information from man login.

Among other things this process will use a number of library calls (via the PAM library, see man 7 pam) to check your credentials, ensure that there are no time restrictions, that your home directory exists, etc. When all the criteria have been satisfied it will discard its privileges and start a copy of your preferred shell. Often (but not exclusively) this is defined as the last field in /etc/passwd.

You can see your own password entry (that strangely, perhaps, does not include even an encrypted copy of your password) with the getentcommand:

getent passwd "$USER"
roaima:x:1001:1001:Roaima:/home/roaima:/bin/bash

More information about the structure of this file can be found with man 5 passwd.

Note that there is no hard and fast requirement for your shell to be /bin/bash. It could be something entirely custom, as it runs only with your own account privileges.

Hopefully this will have explained that the shell itself knows nothing about your credentials. It is just a normal program (a complex one, perhaps) that when running in interactive mode reads from stdin and writes to stdout. The same program can be used in non-interactive mode to read and write to files, pipes, or sockets.

In principle there is little to stop to you writing your own shell that reads a line from its input, splits the words by whitespace, and then forks a child process to call execvpe() and execute a program. (In practice there are a great many extra hurdles to overcome, such as not splitting quoted strings, actioning chdir (cd) directly in the parent, and signals.)