tullis@uiucdcs.UUCP (11/30/84)
What exactly does it mean to "fork a shell"?
marcus@pyuxt.UUCP (M. G. Hand) (12/02/84)
> What does it mean "to fork a shell?"
It depends on the context. It may mean that the program forks, and then execs
a shell to perform some command (for example system(3)), or it may mean
the mechanism by which the shell executes commands itself (ie by forking and
and then execing). Either way, its a fairly loosely expressed term whose
meaning should be evident from the context.
marcus hand (pyuxt!marcus)faigin@ucla-cs.UUCP (12/05/84)
>> What does it mean "to fork a shell?" As a sidenote, ISOS (an 8-bit Unix like system by 4-phase) has a command called "spoon" which does a combined fork and exec. In a similar vein, another system I know of (but can't remember which one) has its "more" like command called "dog" (to go along with "cat") -- | Daniel P. Faigin | (This space intentionally University of California at Los Angeles | left blank) | UUCP: {cepu|ihnp4|trwspp|ucbvax}!ucla-cs!faigin | ARPA: faigin@UCLA-CS.ARPA | USPS (Home): 11743 Darlington Avenue #9 | Los Angeles CA 90049 | (213) 826-3357 |
rcook@uiucuxc.UUCP (12/06/84)
In simpler terms, it means to start up another process running (usually) running parallel with the process being forked from.
ark@alice.UUCP (Andrew Koenig) (12/06/84)
This is a common method of breaking eggs.
greenber@acf4.UUCP (12/08/84)
<> C'mon....lets give this guy some info, folks.. In UNIX a process is really nothing but a collection of entries in a number of tables. The process table has one entry for each process. Each process also has additional entries in other tables. Some of these entries point to where the text (instructions) for the process reside, others point to the files that the process has open, etc. UNIX really is just manipulating table entries. When you fork a process, you are actually creating an exact (well almost!) duplicate of all the various tables and their entries. In fact, if you have a program that forks itself, there is only one way of telling which process is the parent and which is the child: the fork call returns the childs process id to the parent, and returns a zero to the child (unless there is an error condition, of course!) The next step in "forking a shell" is usually the 'exec' call. This call replaces the text (instruction) and data area for the process with something new and entirely different: a new program. This program COULD be a new shell, or anything else that you consider a program. Only certain parts of the old process (pre-exec, as it were) are preserved including, but not limited to, the environmental variables. The child inherits EVERYTHING from the parent, including open files, file pointers, etc. The interesting thing (to me, at least) about UNIX is that the only difference between a backround process and a foreground process is that the shell that was fork/exec'ed to the new piece of your bug-free program doesn't wait for the death of its child. Now some UNIX guru is about to come down from on high and tell us that I was wrong about something, or that I left out some vital piece of information. Well, let me get my umbrella before the downpour.. Hope this helps a little... Ross M. Greenberg @ NYU ----> allegra!cmcl2!acf4!greenber <----
alan@drivax.UUCP (Alan Fargusson) (12/10/84)
> >> What does it mean "to fork a shell?" > > In a similar vein, another system I know of (but can't remember which one) > has its "more" like command called "dog" (to go along with "cat") > It is Zilog's ZEUS system that has "dog". -- Alan Fargusson. { ihnp4, sftig, amdahl, ucscc, ucbvax!unisoft }!drivax!alan
sean@ukma.UUCP (Sean Casey) (12/13/84)
"Forking a shell" is not just creating another process. It is creating a process that is running a shell. Sean