Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!cornell!batcomputer!itsgw!imagine!pawl21.pawl.rpi.edu!jefu
From: jefu@pawl21.pawl.rpi.edu (Jeffrey Putnam)
Newsgroups: comp.os.misc
Subject: Re: OS features
Message-ID: <174@imagine.PAWL.RPI.EDU>
Date: 19 Dec 87 14:42:47 GMT
References: <1971@cup.portal.com> <1169@nmtsun.nmt.edu> <170@imagine.PAWL.RPI.EDU>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: userft4z%rpitsmts@itsgw.rpi.edu
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 40

In article <170@imagine.PAWL.RPI.EDU> beowulf!lunge!jesup@steinmetz.UUCP writes:
>[comments about tops-20 command completion]
>Another interesting idea is Stratus VOS's 'display form' method.  VOS has
>VERY wordy commands, though luckily you can have aliases (for example,
>cd is 'change_current_directory' (No joke!)).
>If you have partly made a command line, you can hit the 'display form' key
>(it could be escape on another terminal).  It puts up a full-screen form
>of all the options for the command, with all the current values you entered
>and the defaults.  You can move the cursor around, changing things according
>to the type of field (things like a series of enumerated entries can be
>cycled, like for example, baud rates.)  When you're done you hit enter or
>cancel.  It is abolutely WONDERFUL when you aren't familiar with the specific
>command and don't want to have to read the docs to figure out the arcane
>1-char switchs ala UNIX.  You can also ask it to give you a 1 (or maybe more)
>liner detailing the command and options.

Yup, the Stratus command line form stuff is really nice, but i dont think its
inherently part of the operating system.  I have worked out two ways to 
implement it in unix, one in the executables, which is nice because it would
help to document the code and options, and one which would run in the shell
and would use a separate file describing the options.  

I say that it is nice, but it also has serious flaws.  You cant get at the
mechanism (or couldnt when i was using it, things may have changed) to use
it in any other context, and you couldnt (for example) build a tree menu
structure with it.  

The important point here is not what the command processor does or doesnt 
do, or what language is used by the shell, or what spiffy features you 
can get at, but what parts of this are inherently part of the operating
system.  Things like the name structure for the filesystem, the 
way that files are built and accessed, the way that processes are handled...
That is the essential part of the operating system, not the command language
or neat features like forms for entering program options.  

I havent used REXX and dont know much about it, but see no reason why a 
REXX interpreter could not be built for Unix.  However, i do note that
many operating systems make many things difficult (for example, building
a REXX interpreter for VMS would probably be more difficult, where building
one for a Lisp machine might be easier).