Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!imagine!pawl18.pawl.rpi.edu!jefu
From: jefu@pawl18.pawl.rpi.edu (Jeffrey Putnam)
Newsgroups: comp.os.misc
Subject: Re: OS features
Message-ID: <184@imagine.PAWL.RPI.EDU>
Date: 1 Jan 88 12:00:32 GMT
References: <1971@cup.portal.com> <1169@nmtsun.nmt.edu> <170@imagine.PAWL.RPI.EDU> <174@imagine.PAWL.RPI.EDU> <182@imagine.PAWL.RPI.EDU>
Sender: news@imagine.PAWL.RPI.EDU
Reply-To: You cant get here from there.
Organization: RPI Public Access Workstation Lab - Troy, NY
Lines: 43

In article <182@imagine.PAWL.RPI.EDU> beowulf!lunge!jesup@steinmetz.UUCP writes:
After some discussion about the command line parameter parser and visual
entry mechanism that Stratus offers in their VOS.  (offered?, its been 
a while).  I mentioned i had worked out a couple ways to implement something
similar in Unix.

>	And they are?  (I would like to see them, maybe put them in my
>shell under AmigaDos.)

I figured to start with a language to describe the command line
options - it would look rather like the Stratus one, but would be a
little more powerful (allowing conditionals and constraints among
variables). It would look rather the same under the shell or in C.  
To work it in the shell, i would trap interrupts and on the appropriate
one (which would be tied to a particular key, like on the stratus) 
invoke a file named like the first part of the command with a specific
extension, this file would contain the option descriptions and would
do the display, parse the options and finally construct the command line
and invoke the program with the correct options.  

Roughly the same thing can be done to parse the options in the 
executable itself - but the signal handling can get hairy (i had
a very complex scheme that might or might not work).  

This does pose an interesting question though:  What exactly would need
to be done in Unix to make this possible - or better, easy?

>	Well, there was the forms manager, but that wasn't really the same
>thing, as you had to program all the interactions yourself.
>(Whipping out my VOS manuals, and choking on the dust...)
>Page 203, Service Subroutines:  s$parse_command().  And you're right,
>Jeff, it only looks at the command line (note that my manuals are several
>years out of date.)  Boy, is it powerful, though.

Exactly my point about magic (im agin it).  Any system that has things
in it whose mechanism is not precisely documented tends to make things
much more difficult for the programmer.  Good examples are the Stratus
visual command line processor, the VMS CLI mechanism (though i understand
its documented now) - and so on (most systems have them, some have many).
Unix doesnt tend to have them because the source has been available, and
thus I deprecate the tendency to hide the source.  

jeff putnam