On Sun, Jun 06, 2004 at 07:20:54AM +0530, snodx@xxxxxxxxxxx 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@xxxxxxxxxx -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
