Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!cornell!batcomputer!itsgw!imagine!pawl11.pawl.rpi.edu!jesup From: jesup@pawl11.pawl.rpi.edu (Randell E. Jesup) Newsgroups: comp.os.misc Subject: Re: OS features Message-ID: <182@imagine.PAWL.RPI.EDU> Date: 27 Dec 87 23:01:46 GMT References: <1971@cup.portal.com> <1169@nmtsun.nmt.edu> <170@imagine.PAWL.RPI.EDU> <174@imagine.PAWL.RPI.EDU> Sender: news@imagine.PAWL.RPI.EDU Reply-To: beowulf!lunge!jesup@steinmetz.UUCP Organization: RPI Public Access Workstation Lab - Troy, NY Lines: 66 In article <174@imagine.PAWL.RPI.EDU> userft4z%rpitsmts@itsgw.rpi.edu writes: >In article <170@imagine.PAWL.RPI.EDU> beowulf!lunge!jesup@steinmetz.UUCP writes: >>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. And they are? (I would like to see them, maybe put them in my shell under AmigaDos.) >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. 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. >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 agree. But the discussion had turned from 'whose operating system had the most useful features' to discussion of the command interpreters, which while not the core of the OS, or even standard (unix's sh and csh), are still important characteristics of OS's. Remember a lot of what one sees of an OS is filtered through the shell and utilities. >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). I'm just starting to play with Rexx on my Amiga (VERY nice implementation), and I'm sure it could be done for Unix. It would not be quite as powerful under Unix because of differences in input/output handling. However, for programs written to interact with it, it is wonderful. On CMS I believe it can be used without the underlying program having to be written accept commands from an external language (it leeches off the input stream, or some such). And doing it for VMS would be a bear :-) // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// lunge!jesup@beowulf.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup)