Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!uxc!iuvax!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.arch
Subject: Re: Shells everywhere (was Re: Cobol Data Corporation Cyber 180 ...)
Summary: Shells are easy to fake
Message-ID: <10333@pur-ee.UUCP>
Date: 17 Jan 89 15:54:58 GMT
References: <10847@tekecs.TEK.COM> <1185@esunix.UUCP> <413@laic.UUCP>
Organization: Purdue University Engineering Computer Network
Lines: 39

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