Newbie Question - What is actually executing the binary?

[Dave Ihnat]

On Sun, Jun 06, 2004 at 07:20:54AM +0530, snodx at hotmail.com wrote:
> Here is the question, any thing that I type on Redhat's command terminal,
> where is the command terminal actually sending it to? For eg if I
> type say "ls -l" what is actually executing the "ls" binary in the
> back-end? Which is the software program that is opening the "ls"
> binary executable file, traversing through the binary instructions
> in this file, understanding it and executing it?

Please note that I'm doing a LOT of simplification in the following;
please allow for that if, in investigating this further, you find any
omissions...

The command interpreter--the shell--is a program, like any other program.
(This was a rather remarkable departure from more traditional operating
systems when it was introduced by Unix.  To that point, the command
interpreter was either a privileged program, or an extension of the OS
itself.)  Any one of a number of possible shells may be specified as the
login shell for an account; look at your account's entry in /etc/passwd,
and do a "man 5 passwd".  Whenever the system starts up in multiuser mode,
the "init" program (look at /etc/inittab, do "man init") spawns a program
called getty.  It conditions the communications link--virtual console or
serial line--and issues the login prompt.  (Things are slightly different
for connections over the network; do a man on, for instance sshd.
But they're close enough that this explanation will give you the idea.)

Once you reply with a user ID, the "login" command is spawned--it actually
replaces the "getty" command in memory (do "man execl")--with the user ID
as an argument.  Login actually issues the "password" prompt.  Once you're
authenticated, login is replaced with the shell command specified in the
/etc/passwd file for that account.

By and large, all CLI (command line interpreters) work the same way.
They have a number of reserved words that are directives to the
shell program-- commands that create, set, or delete shell variables;
control constructs for looping, conditional tests, etc.; some direct
interfaces to the operating system services; and so on.  Otherwise,
if something is typed that isn't recognized as one of these internal
directives, it's assumed to be a request to execute a shellscript or
executable program.  A file with the same name as the command entered
is searched for, using the PATH environment directive.  If found, the
proper arguments are constructed from the remainder of the input command
line to permit issuance of some form of the "fork" and then "execl"
kernel requests to load the target program and transfer control to it,
temporarily suspending the shell until that target program terminates.
If the target is a shellscript, another copy of the shell itself is
spawned to process the script as input commands.

> Which kernel program is recieving the instructions from the shell?

Not a program, per se.  Whenever a request--either from an internal shell
directive, or just the request to spawn a new program--requires a service
from the kernel, it makes a kernel call.  In the traditional Unix form,
all kernel service calls are documented in section 2 of the manual set;
for instance, do "man 2 read".  What generally happens--in Unix, Linux,
or any protected-mode operating system--is that the library interface to
the call is linked into the program when the executable is built (most
come from libc, some from a handful of other special support libraries).
When called from the user code, this linkage interface--also running in
the user process space--performs necessary validation and collection
of arguments, and stores them in a special memory area of the program
stack or process space reserved for argument transfers, then causes a
software exception or interrupt to be issued.  This exception is reserved
for kernel requests; at this point, the user process is suspended,
privileges are changed and control is transferred to kernel execution.
The interrupt vector code carries out any necessary housekeeping (usually
also including transferring arguments to kernel- accessible space) and
then looks up the requested service in some manner-- usually a table of
user interface functions--and, if found, transfers control to that function.

Now things get strange--there are process prioritization issues, and deferred
requests, and all sorts of OS stuff--that can happen.  But eventually, the
kernel returns the results from the request, which again are processed to make
any necessary data accessible to user-level code, including the status code,
and the privileges are dropped back to user-level and the user process is
resumed.  In the shell, this usually means it at least provides the return
status code, e.g., "$?", and then returns to listening for more input.

> Sorry for this dumb question. I did'nt where else to post it.

Not dumb--it's important to understand.  But it really needs more info than
you can get from a posting to really understand it.

Cheers,
-- 
	Dave Ihnat
	ignatz at dminet.com