What does an operating system look like before a shell is run?
Depends on the OS and how you configure it. Linux can be configured to write boot text to a console device, whether a text mode console, framebuffer console or a serial port. It can also be configured to be perfectly silent. Some OS's/systems may write diagnostic information to a non-volatile memory that can be accessed by putting the system in developer, debug, or diagnostic mode. Many operating systems support outputting boot and diagnostic information to some form of UART, which may somehow be available on the unit even if hidden from the user (google "Add serial port to DD-WRT" for examples of where manufacturers hide serial ports and how you can get to them).
An OS doesn't have to have an external display at all - it's just another device to the OS.
How were systems used before the first shell was developed (e.g. UNIX
in the early 1970s)?
Essentially (and leaving out a lot but this should get you the idea) - You loaded your program, either by flipping switches on a panel or using a paper-tape reader (these devices would write to memory directly without CPU intervention) and then start the CPU with another switch. The CPU would run this program, generate its output, and stop. This is batch processing as opposed to interactive processing. If you wanted to run a different program you had to do this over.
If a computer cannot even accept commands (there is no command line),
how can a user interact with it?
I am no expert in this area but old, old computers like the Altair, IMSAI, and PDP-8 and such had front panel switches that directly controlled the CPU and could directly read and write memory without CPU intervention.
What is this most basic interface?
I believe most if not all modern CPUs have a "JTAG port" which allows the same type of direct operations. Keep in mind that for a long time most computers have been expected to have ROM or firmware that takes control of the system when it is turned on before it hands it off to an OS. Here, pre-boot utilities can exist, or a minimal mechanism for loading such utilities exists. Some bootloaders such as U-Boot can be accessed via the serial port.
Bootloaders don't run "behind" the OS, they load the OS, hand control to it, and then they are no longer running.
Can I run this interface in a
terminal emulator or is there no way going behind a shell?
No, you need a JTAG interface. That's diving into the realm of electronics and I admit I don't know very much about it, except that my GuruPlug comes with one and I can directly program the flash chip on the GuruPlug's board with it - meaning if something kills the bootloader on the GuruPlug, I have a "CPU independent" way of flashing it back.
Best Answer
The traditional way that the terminal logon process worked under Linux (and other Unix systems) before
systemd
is the following:init
is configured to keep one or moregetty
processes running - meaning when thegetty
process exits,init
will start it again.Each
getty
opens a device that needs to have a login prompt. This can be the virtual ttys on the text-mode screen/dev/tty0
etc., or actual serial ports/dev/ttyS0
that you can still connect a classical real terminal like a VT220 if you still wanted to, or have modems connected to for dial-in capability.getty
outputs the/etc/issue
and[hostname] login:
prompt on the device it's told to open (usually specified in theinittab
line) and waits for a username and password.If it's correct, it will open the shell of the account with an
exec()
style-system call.What
exec
does is replace the current process with a new executable. Since the actual PID didn't change,init
isn't triggered to restart anything yet. Since the shell is running and has replacedgetty
, another login can't happen on that terminal.When the user is done and closes the shell,
init
gets a signal.init
then launches a newgetty
which asks for a login prompt again.In this situation,
getty
is not a daemon - it's a non-background program waiting for input on a terminal. You might not be looking at the terminal, but it's still there in the foreground waiting for someone to input a username and password. And the shell is definitely not a daemon - it simply getsexec
'ed over thegetty
and is a normal foreground program just like thegetty
it replaced.Now - most all Linux systems run
sshd
which is a daemon, and it works completely differently.sshd
handles the SSH protocol setup and and handles the login prompt over that SSH connection by itself - nogetty
's are involved withssh
. However whenssh
receives a valid username/password it uses a different system callspawn()
which creates a new child process. The shell is still not a daemon in this case.For graphical logins, the desktop manager handles logins;
gdm3
for example.getty
's are not involved since setting up a GUI session is more complex than justexec
'ing a shell.systemd-logind
- which is a daemon - doesn't really change things very much for terminal login, though. It basically takes the place ofinit
for spawninggetty
's on terminals, but thegetty
processes are still handling the logins in the same way--and when theexec
'ed shell exits,systemd-logind
is then triggered to restart a newgetty
.