andrew@frip.gwd.tek.com (Andrew Klossner) (01/12/89)
[]
"It should be possible to write a shell for almost any usable
computer ..."
A shell requires that the system supply fork() and exec(), or perhaps
start_task() (fork and exec combined) system services, or something
analogous and reasonably efficient. Lots of "usable computers" don't
have these. Two examples that come to mind are the original PDP-10
running TOPS-10, and IBM CMS under VM/370: each user got exactly one
virtual address space, in which to run exactly one task (although CMS
would let you slip a second small task into a couple of pages reserved
for that purpose, to run while the primary task was suspended).
MSDOS is also a single tasking system (today, at least), but you can
write a shell for it by slipping a few tentacles into the (unprotected)
kernel. This wouldn't work under TOPS-10, because there's no way for a
shell coexisting with a user task to get control when the task exits.
To do it under CMS, you would have to run a non-shared copy of the
kernel so as to write-enable it; this adds page fault time.
-=- Andrew Klossner (uunet!tektronix!hammer!frip!andrew) [UUCP]
(andrew%frip.gwd.tek.com@relay.cs.net) [ARPA]elg@killer.DALLAS.TX.US (Eric Green) (01/13/89)
in article <10847@tekecs.TEK.COM>, andrew@frip.gwd.tek.com (Andrew Klossner) says:
$ "It should be possible to write a shell for almost any usable
$ computer ..."
$ A shell requires that the system supply fork() and exec(), or perhaps
$ start_task() (fork and exec combined) system services, or something
$ analogous and reasonably efficient. Lots of "usable computers" don't
$ have these. Two examples that come to mind are the original PDP-10
$ running TOPS-10, and IBM CMS under VM/370: each user got exactly one
$ virtual address space, in which to run exactly one task (although
A seasoned critic would respond, "I thought you said USABLE
computers!"
(Caveats: I have used VM/CMS -- unfortunately. I have not used
TOPS-10. My computer at home is an Amiga.)
--
Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg
Snail Mail P.O. Box 92191 Lafayette, LA 70509
Netter A: In Hell they run VMS.
Netter B: No. In Hell, they run MS-DOS. And you only get 256k.rpw3@amdcad.AMD.COM (Rob Warnock) (01/13/89)
In article <10847@tekecs.TEK.COM> andrew@frip.gwd.tek.com writes: +--------------- | | "It should be possible to write a shell for almost any usable | | computer ..." | A shell requires that the system supply fork() and exec(), or perhaps | start_task() (fork and exec combined) system services, or something | analogous and reasonably efficient. Lots of "usable computers" don't | have these... [can hack] by slipping a few tentacles into the (unprotected) | kernel. This wouldn't work under TOPS-10, because there's no way for a | shell coexisting with a user task to get control when the task exits. +--------------- Well... actually there is a way, at least for TOPS-10 programs that use the (semi)standard command parser subroutine "SCAN". Unlike Unix's "getopt()", SCAN provides both standard switches (options) and program-specific switches. For example, the standard built in switch "/HELP:SWITCHES" will cause a dump of all the switch names. Another one of the built in switches is "/RUN:<program_name>", which causes the program to "exec" (in the Unix sense) "program_name" when it's done instead of exiting. SCAN also supports indirect command files, and the switch "/RUNOFFSET:1" causes the SCAN parser in the chained-to program to look for an indirect command file in a known place. Putting this all together... A TOPS-10 "shell" could write an indirect command file for each program in a (pseudo)pipeline, each command file naming shell-generated temp file names to use for the "pipe" files (a la MS-DOS "pipes"), each chaining to the next program in the pipeline, and have the last program chain back to the shell itself. Doesn't give you concurrent execution of the processes in the pipeline, nor does it give you trivial background jobs (although the shell could submit a job to the "BATCH" system!), but you *could* at least do stuff like "some_prog | grep pattern | sort ". Note that this is in fact how TOPS-10's compile/load/go commands already work. When you say "EXEC FOO", you actually run the program "COMPIL", which performs a (trivial) "make"-like function, then builds command files as needed for the compiler (figuring out what compiler to use from available "FOO.XXX" files) and link/loader, which then chain to each other and finally to FOO.EXE. The only thing missing is to get FOO to chain back to a "shell". And since VM/CMS supports several flavors of command-file processor (EXEC, EXEC2, REXX), I'll bet you a Unix-like "shell" could be written to run under CMS, too. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
bpendlet@esunix.UUCP (Bob Pendleton) (01/13/89)
From article <10847@tekecs.TEK.COM>, by andrew@frip.gwd.tek.com (Andrew Klossner): > [] > > "It should be possible to write a shell for almost any usable > computer ..." > > A shell requires that the system supply fork() and exec(), or perhaps > start_task() (fork and exec combined) system services, or something > analogous and reasonably efficient. Well... sort of. Anyone remember Exec-8 on the Univac 1100 series? I saw a shell on an 1108 that worked by creating a file consisting of the commands needed to run a program and a command to restart the shell. The shell would then @ADD the file to its input stream and terminate so that the commands in the file would be executed. Analogous to fork() and exec()? I don't think so. Reasonably efficient? No. Did it work? Yes. Was it a shell? Yes. > > MSDOS is also a single tasking system (today, at least), but you can > write a shell for it by slipping a few tentacles into the (unprotected) > kernel. Wouldn't it just be easier to write a shell as a replacement for COMMAND.COM? A program running under MSDOS can load another program into unused memory, start it running and be awakened when the program terminates. Check out the SHELL verb under MSBasic or spawn under TurboC 2.0 for examples. This ability makes it possible to write quite a reasonable shell under MSDOS. Check out "Software Tools" by Kernighan & Plauger(SP?) for more information on how to write a shell for OSs that don't support UNIX system calls. I can't comment on Tops-10, but I'm pretty sure there were shells on Tenex and Tops-20. Bob P. -- Bob Pendleton, speaking only for myself. UUCP Address: decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet Reality is what you make of it.
swilson%thetone@Sun.COM (Scott Wilson) (01/17/89)
In article <1185@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes: >Wouldn't it just be easier to write a shell as a replacement for >COMMAND.COM? > >A program running under MSDOS can load another program into unused >memory, start it running and be awakened when the program terminates. >Check out the SHELL verb under MSBasic or spawn under TurboC 2.0 for >examples. This ability makes it possible to write quite a reasonable >shell under MSDOS. > >Check out "Software Tools" by Kernighan & Plauger(SP?) for more >information on how to write a shell for OSs that don't support UNIX >system calls. For those interested, there is a book by Allen Holub called (I think): On Command, a UNIX like shell for DOS. Anyway, it's something close to that and describes how to write a UNIX-like shell for DOS. Either floppies come with it or can be purchased separately that have source and executables. All of this is from memory so the details may be somewhat fuzzy. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
darin@nova.laic.uucp (Darin Johnson) (01/17/89)
>From article <10847@tekecs.TEK.COM>, by andrew@frip.gwd.tek.com (Andrew Klossner): >> [] >> >> "It should be possible to write a shell for almost any usable >> computer ..." >> >> A shell requires that the system supply fork() and exec(), or perhaps >> start_task() (fork and exec combined) system services, or something >> analogous and reasonably efficient. Most OS's don't use fork(), it is a very UNIXish call. A lot do have exec() type thingies, but they are used for chaining and stuff like that. Most OS's run each command in the same process as the command interpreter. For example, VAX/VMS loads in new commands in P0 address space, and the command interpreter (or debugger) resides in P1 space (I may have P0/1 backwards..). However, these sorts of command interpreters can still be considered "shells". This method is probably more efficient as fork/exec, but probably not as versatile. However, writing your own for VMS is no easy task (no documentation). Even DEC, when they came out with a Bourne Shell look-a-like (which I expect was designed to turn people off to UNIX), designed it to create a new process for each command (it caches old processes for some efficiency) which is horribly inefficient, as process creation is slow. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) "You can't fight in here! This is the war room.."
hankd@pur-ee.UUCP (Hank Dietz) (01/17/89)
In article <413@laic.UUCP>, darin@nova.laic.uucp (Darin Johnson) writes: > >From article <10847@tekecs.TEK.COM>, by andrew@frip.gwd.tek.com (Andrew Klossner): > >> "It should be possible to write a shell for almost any usable > >> computer ..." > >> > >> A shell requires that the system supply fork() and exec(), or perhaps > >> start_task() (fork and exec combined) system services, or something > >> analogous and reasonably efficient. > > Most OS's don't use fork(), it is a very UNIXish call. A lot do have ... > However, writing your own for VMS is no easy task (no documentation). > Even DEC, when they came out with a Bourne Shell look-a-like (which I > expect was designed to turn people off to UNIX), designed it to create > a new process for each command (it caches old processes for some > efficiency) which is horribly inefficient, as process creation is > slow. All that is needed is a chaining/batch mechanism. Way back, under dinosaurs such as CP/M, I had a unix-like shell running using SUBMIT files. Basically, if you told the shell to run "blah yick yuck" it would write a SUBMIT script which ran "blah yick yuck" and then itself -- running itself with a command-line option saying where it had saved the shell state (an ordinary file). Running the shell without this option gave you a clean shell state. Redirection and multiple processes were not supported by CP/M. However, redirection and pipes were supported for commands built-into the shell (which included date, cat, cp, mv, ls, etc.) and other programs that the shell knew about (via a table of known "friends") also could do redirection and pipes via temporary files whose usage syntax was supplied by the table entries describing the programs. I even had a unix-style login. The largest problem -- and it is nasty -- is that CP/M SUBMIT files could generally be broken by typing a ^C. Oh well. Anyway, the point is that the unix shell, but not the unix environment, is easily placed upon just about anything. Unfortunately, it isn't enough (:-). -hankd@ee.ecn.purdue.edu
dave@lethe.UUCP (David Collier-Brown) (01/18/89)
From article <10847@tekecs.TEK.COM>, by andrew@frip.gwd.tek.com (Andrew Klossner): >> "It should be possible to write a shell for almost any usable >> computer ..." From article <1185@esunix.UUCP>, by bpendlet@esunix.UUCP (Bob Pendleton): > I can't comment on Tops-10, but I'm pretty sure there were shells on > Tenex and Tops-20. Yup, and its getting a bit far from architecture, folks. --dave (writing from a cp/m machine with a shell called sh) c-b
jms@antares.UUCP (Joe Smith) (01/18/89)
In article <10847@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: >A shell requires that the system supply fork() and exec(), or perhaps >start_task() (fork and exec combined) system services, or something >analogous and reasonably efficient. Lots of "usable computers" don't >have these. Two examples that come to mind are the original PDP-10 >running TOPS-10, and IBM CMS under VM/370. > [deleted] >write a shell for it by slipping a few tentacles into the (unprotected) >kernel. This wouldn't work under TOPS-10, because there's no way for a >shell coexisting with a user task to get control when the task exits. > -=- Andrew Klossner (uunet!tektronix!hammer!frip!andrew) [UUCP] Your example is referring to how TOPS-10 used to work. Release 7.03 introduced alternate contexts. From the command level, you can type Control-C to stop execution, type PUSH to get an alternate context, do a bunch of stuff, type POP to get back to the original context, and finally type CONTINUE. Some commands (such as HELP) are defined as auto-push, so they do not wipe out your "core image". From the system call level, a program can execute a CTX. uuo which will run a program in another context and report back the ending status. A similar feature exists in the OS that Tymshare created for their PDP-10's. The frame-run option to the FRMOP uuo creates a child frame, runs a program, and reports ending status. ______________________________________________________________ There is one feature of TOPS-10 that I have yet to see duplicated. That is the ability to scan up the directory heirarchy automatically when a file is openned for reading and does not exist in the current directory. For example: I have the sources to TOPS-10 in [10,11,TOPS10,703]*.MAC and my default directory is [10,11,TOPS10,703,TEST] with the /SCAN bit set. If I type ".COPY COMCON.MAC=COMCON.MAC" and [10,11,TOPS10,703,TEST]COMCON.MAC does not exist, the OS will find the file in [10,11,TOPS10,703]COMCON.MAC on the LOOKUP and PIP will duplicate it in the default directory. Editing this file will modify only the copy in the TEST directory, leaving the original alone. When it comes time to assemble and load the monitor, the linker will use the modified modules from the TEST directory and automatically find the unmodified modules in the directory above it. With TOPS-10 it is easy to tell when to stop scanning up the directory tree; it stops when it comes UFD (User File Directory). I could see where an OS like UNIX might have a problem in determining where to stop the scan (so as to not go all the way up to the root). -- Joe Smith (408)922-6220 | JMS@antares.Tymnet.COM[131.146.3.1] or jms@opus McDonnell Douglas FSCO | UUCP: {ames|pyramid}oliveb!tymix!antares!jms PO Box 49019, MS-D21 | PDP-10: JMS@F74.Tymnet CA license plate: "POPJ P," San Jose, CA 95161-9019 | (this line reserved for my Amiga 2000)