Path: utzoo!attcan!uunet!lll-winken!ames!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.arch
Subject: Re: Shells everywhere (was Re: Cobol Data Corporation Cyber 180 ...)
Message-ID: <24044@amdcad.AMD.COM>
Date: 13 Jan 89 10:44:45 GMT
References: <28200249@mcdurb> <451@babbage.acc.virginia.edu> <1951@scolex> <1121@raspail.UUCP> <2618@ficc.uu.net> <5657@cbmvax.UUCP> <10847@tekecs.TEK.COM>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 53

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