Mark_G_Woodruff@cup.portal.com (12/13/87)
Following are the replies to my query about operating system features people
liked. Comments followed by a bullet (yes, it's really a lower case o)
are summaries of what the person said. Comments followed by a right
arrow (yes, it's really a greater-than sign) are more-or-less verbatim
(minor editing changes only). Anything in brackets are my own remarks.
From: Michal Young <young@bastille.UCI.EDU>
o Device-independent stream I/O, for files and for terminals (a la Curses)
o A shell command language with control structures and job control (a la
csh)
o Remote command execution and remote file systems (a la Sun NFS)
o Reentrant libraries (a la Vulcan [a HORRIBLE os])
o Dynamic run-time linking (a la MVS [or Smalltalk])
> Command completion (The DEC OS's get this better than Unix)
[Could you please elaborate?]
o History substitution (a la csh)
> Synchronous mail notification (before a prompt)
[Again, please explain.]
From: sun!RUTGERS.EDU!uwvax!ncc!alberta!edson!tic!ruiu (dragos)
> The one thing I miss on unix from VMS more than anything is pressing
> control T and seeing the cpu time or the i/o changing in my program,
> and knowing wether it's just the system thrashing or wether something
> is seriously hung. It's a little thing... Boy, if I had Kernel
> source... :-)
> VMS has another nice feature... it degrades gracefully under pressure.
From: Paul Fuqua <pf@relief.csc.ti.com>
> Tops-20: the COMND jsys -- completion and help in every command.
[Please explain.]
> (MIT version) Chaosnet as a device -- "copy foo cha:xx.send_pf" would
> copy the foo file as the text of a "send" ("write" in BSD Unix) to user
> "pf" on host "xx" via Chaos."
> Lisp Machines: No clear distinction between OS, environment, and
> programs -- all functions are treated equally, all processes are visible.
> Easy accessibility to all functions, variables, and constants --
> prototyping is much easier when one can steal from existing examples.
[Smalltalk does this well.]
From: ian@sq.com (Ian F. Darwin)
> For a brief description of the salient features that I like
> about UNIX, please read the paper
> The UNIX Time-Sharing System
> D. M. Ritchie, K Thompson
> CACM 17 N 7, July 1974, pp 363.
> Revised edition in Bell System Tech J, V57, N6, July-Aug 1978.
> I have used more operating systems than I have fingers, and the
> reasons I prefer UNIX are in the paper, for the most part.
From: meissner@xyzzy.DG.COM
Features in AOS and AOS/VS
o Generalized searchlists (where the searchlist is searched for all file
accesses instead of just for execution requests)
o More powerful access control and more permissions
[The best example I've seen of this is the Novell Advanced Netware
package. Novell allows you define multiple groups of
individuals, name them, then give various rights for each file
or directory according to group as well as individual names. The
result is effective, powerful, and, when combined with their user
interface, very easy to use.]
o Screen-editing in all console I/O (so that your basic editing functions
are always available)
From: John Hanley <hanley@cmcl2.NYU.EDU>
> Most important feature: coherent design
o A standard calling convention so that programs in one language can
call programs in other languages (a la VMS)
o Integrated security
From: gerry@uunet.UU.NET (G. Roderick Singleton)
> I still like CP/M. For all its faults, it provided phenomenol control
> over the installed evironment even without sources. The CP/M community
> added to its usefulness.
o A rich tool set (a la UNIX)
From: uunet!nuchat!sugar!peter
> Setuid bit in UNIX. Brilliance.
> UNIX directory structure. Inodes/links.
> Berkeley symbolic links.
[Please explain.]
> VMS/AmigaDOS symbolic names.
[Please explain.]
> RMD in RSX.
[Please explain.]
> Signals in UNIX: in general being able to write interrupt-like handlers
> in a process context in a high level language.
> Message passing between totally isolated parts of the O/S in AmigaDOS.
> Makes it easy to add drivers.
> Being small and tight is good. Taking features out if it helps is good.
> Version 7 is a better designed O/S than either System V or Berkeley.
From: marzullo@gvax.cs.cornell.edu (Keith Marzullo)
o An integrated environment, and an open architecture
> I also have really appreciated all systems that support spy hooks, or
> what Jeff Mogul calls packet filters in his paper in the latest SOSP.
> Not only have they served as another way to quickly prototype protocol
> families, they allow one to write some very powerful monitoring tools.
[Can you tell us more?]
From: sun!texsun!killer!jfh (The Beach Bum)
> RT-11. I liked having real hardware sitting under my software. When I
> wanted it.
From: sun!rutgers.edu!moss!ho95e!wcs (Bill Stewart)
> Features I've liked/disliked
>
> Good-Automagic version files, a'la VMS. Whenever you change a file,
> the old one is kept until you explicitly remove it.
>
> Bad-Hierarchical file systems where you need different syntax for each
> level, or need to know what disk something is on, like DOS or VMS.
>
> Bad-Operating Systems that "know" what your files look like
> (e.g. records). It can be valuable to have headers in the
> file that identify it, but the OS should stay out of the way.
From: uunet!pwa-b!mmintl!franka (Frank Adams)
> I was very fond of the command processing on TOPS/20. In particular:
>
> Typing part of a command and question mark, the system tells you what
> commands start with the given prefix.
>
> Typing escape in mid-command, the system guesses what you want next,
> complete with "guide words". (If you don't like it, you can back up, of
> course.)
>
> The fact that the commands were well-named was also a big plus.
From: hoptoad!pdnbah!reggie (George Leach)
o A hierarchical file system
o Heuristic command processing (a la above and Unix 8th edition)
From: "Michael A. Patton" <MAP@AI.AI.MIT.EDU>
> It is really unfortunate that you set the criteria like you did! I
> just received your message and it's already after 1 Dec 87. There is
> an operating system (I.T.S.) which has had many features that are far
> superior (and it's had them for more than 10 years) but few people are
> familiar with it. I would really have liked to describe these, but
> since the time limit was up before I got the request, I guess the
> world will go on losing for another ten years.
[I tried to send you mail asking for more information, but your site
insisted you didn't exist. Could you post a listing of all those
features you talk about?]
From: Mark.G.Woodruff@Cup.Portal.Com
o Virtual Machines. They allow you to code as close (or far) from the
hardware as you like without sacrificing security. They also aid
tremendously when writing operating systems or hardware-dependent
software.
o A common command language for both the editor and the shell. With
Rexx and Xedit under VM, you can use the same command language to
write your editor macros and you shell scripts. This also makes the
editor a much more powerful tool for software building than any
equivalent under Unix.
o An easy-to-learn command language. Rexx is far easier to learn and use
than any other interpreted language I've seen (including Basic, the
shell and cshell languages, Logo, and Smalltalk).
o An object-oriented file system. The designers of Unix made a serious
mistake in forcing all objects in their file system to have the same
format. A much better approach would be to define a common protocol,
then let each object decide how best to implement it.
o Long command and option names that can be abbreviated easily. Unix
is impossible for a novice to use without a manual in large part due
to its poor user interface in this regard.
o Quiet commands. There should be some way of making commands keep
quiet under normal operation. There isn't under VM or MS-Dos.
o A real-time kernal. Essential for a great many tasks.
o A scheduler that takes terminal I/O into account (this is why VM can
handle significantly more users gracefully than any other OS on a
similar class of machine).
o Contiguous file allocation on large devices. The additional overhead
of discontiguous file allocation is unwarranted on modern hardware.
In closing, I'd strongly suggest any OS designers to investigate VM and Novell
Netware. These two systems contain too many unique and useful ideas to be
overlooked.
Markhydrovax@nmtsun.nmt.edu (M. Warner Losh) (12/15/87)
In article <1971@cup.portal.com>, Mark_G_Woodruff@cup.portal.com writes: [[ Mark is summarizing responces that he got and asks for some elaberation.]] > > Command completion (The DEC OS's get this better than Unix) > [Could you please elaborate?] > > Tops-20: the COMND jsys -- completion and help in every command. > [Please explain.] Command completion: This is a simple concept. When the user has typed in enough of the command to make it unique and hits a specified key (usually ESCAPE in TOPS-20), the rest of the command appears "by magic". This may be difficult to understand from a unix point of view, since all of the commands are cryptic beyond believe (they can be learned, but it is painful). In contrast the TOPS-20 and VMS commands are long and verbose, allowing you to know EXACTLY (or nearly so) what is going down. For example, on TOPS-20, to print a file you type @ PRint (file) Foo.txt /Copies:2 Where the uppercase letters denote what the user typed, then hit esacpe to complete rest of the command. The stuff in parens are noice words that allow the user a quick mneumonic reference. These words aren't stictly needed. I'm not exacltly sure about the number of letters in this command, but they are close. Now, you say, this is really stupid that I need to type an escape key many times for each command. You don't have to, as the EXEC on TOPS-20 will alos accept: @ PR FOO.TXT/C:2 @ PRIN FOO.TXT/COP:2 etc. You needn't use the command completion, but it was there if you got stuck. Very useful for learning the system. > > Most important feature: coherent design An obvious plug for VMS...... :-) > > VMS/AmigaDOS symbolic names. > [Please explain.] Symbolic name, also called logical names are in a way similar to environmental variables in UNIX. They differ in that they can be used as file names (that is the OPERATING SYSTEM understands them as such) in any contect where a file name would occure. They have the advantage that you can write code like: fopen ("SPOOL_DIR:tmp", "w"); and have SPOOL_DIR point to something useful. This means that you need not recompile your program to move the spooler directory. You can also change this, in certain cased, WHILE THE PROGRAM is running. From what I have seen, it appears that the symbolic names (which I read as logical names. Somebody correct me if I'm wrong) to be a superset of enviornment symbols. Warner Losh ...!lanl!unm-la!unmvax!warner%hydrovax -- bitnet: lush@nmt.csnet M. Warner Losh csnet: warner%hydrovax@nmtsun uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax Warning: Hydrovax is both a machine, and an account, so be careful.
chris@spock (Chris Ott) (12/15/87)
Mark Woodruff writes: > o Contiguous file allocation on large devices. The additional overhead > of discontiguous file allocation is unwarranted on modern hardware. One of the features of AOS/VS (Data General) that I like is its variable element size. Files are made up of elements of a given number of blocks. For example, if a file's element size is 10 blocks, the file will grow in chunks of 10 blocks at a time. This is great when you're setting up a file that you know is going to be large, and you want to quickly access the data: just set the element size to 30000 or something. Likewise, you don't want to take up 30000 blocks for a file that's only going to be a few lines long, so you can set the element size to 1 block, and only 1 block will be allocated at a time. I haven't seen this feature on any other operating system. Has anyone else? ------------------------------------------------------------------------------- Chris Ott Computer-Aided Engr. Lab Beware of low-flying butterflies. University of Arizona Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris -------------------------------------------------------------------------------
karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) (12/16/87)
chris@spock writes: Mark Woodruff writes: > o Contiguous file allocation on large devices. The additional overhead > of discontiguous file allocation is unwarranted on modern hardware. One of the features of AOS/VS (Data General) that I like is its variable element size. Files are made up of elements of a given number of blocks. For example, if a file's element size is 10 blocks, the file will grow in chunks of 10 blocks at a time... ...I haven't seen this feature on any other operating system. Has anyone else? Computer Consoles, Inc's PERPOS of a couple of years back supported contiguous file creation. You had to give it the total size of the file required, as I recall, no file growth once it's created. PERPOS (a fault-tolerant UNIX derivative) was intended for a heavy transaction-oriented system, which made this sort of use important. -=- Karl
george@rebel.UUCP (George M. Sipe) (12/17/87)
chris@spock writes: > One of the features of AOS/VS (Data General) that I like is its > variable element size. Files are made up of elements of a given number > of blocks. For example, if a file's element size is 10 blocks, the file > will grow in chunks of 10 blocks at a time... > ...I haven't seen this feature > on any other operating system. Has anyone else? karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) writes: >Computer Consoles, Inc's PERPOS of a couple of years back supported >contiguous file creation. You had to give it the total size of the >file required, as I recall, no file growth once it's created. PERPOS >(a fault-tolerant UNIX derivative) was intended for a heavy >transaction-oriented system, which made this sort of use important. Fair warning: Description follows of product by a company with which I have absolutely no association other than as a full time employee :-). Tolerant's TX (a distant 4.2 derivative) allocates files by extents rather that blocks. Each file may have one primary extent and as many secondary extents as necessary. Both extent sizes may be from 1kb to 8mb in even powers of 2. Each file system has defaults for both primary and secondary extents (usually 8kb). Extent sizes are set by a setext() system call on files of null length. An extentsize() library call determines optimal extent sizes (to need only 1 inode) for a file given an expected filesize. Cylinder boundaries are taken into account during allocation, free space is recombined on removal. All system commands (e.g. tar) set extents. Existing programs benefit from the addition of the setext() call, but run no worse without it then they do on most other Unix systems. This system is fully fault tolerant, designed for high performance communications systems and OLTP applications (transaction management is integral). -- George M. Sipe, Phone: (404) 662-1533 Tolerant Systems, 6961 Peachtree Industrial, Norcross, GA 30071 UUCP: ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!rebel!george
mac3n@babbage.acc.virginia.edu (Alex Colvin) (12/17/87)
In article <3228@tut.cis.ohio-state.edu>, karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) writes: > > o Contiguous file allocation on large devices. The additional overhead > > of discontiguous file allocation is unwarranted on modern hardware. See the article by P. Koch on DTSS File systems in the latest Trans. on Comp. Sys.
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (12/17/87)
Mark Woodruff writes: > o Contiguous file allocation on large devices. The additional overhead > of discontiguous file allocation is unwarranted on modern hardware. Unicos (Cray's System V for their hardware) has transparent support of files with large contiguous chunks, and an IO system that takes advantage of them. Each unix file system is broken up into two or more partitions (these aren't unix partitions, but are more like the BSD cylinder groups). The first partition is dedicated to special files, most notably directories. Blocks for a data file are allocated contiguously as long as no one else needs blocks in the partition. File creation round-robins through all but the first partition of the file system, to give the processes writing each file as much time as possible to grow the file. Unicos also supports disk striping. The results work fairly well, but I don't know how much is do to which activity. <mike -- And then up spoke his own dear wife, Mike Meyer Never heard to speak so free. mwm@berkeley.edu "I'd rather a kiss from dead Matty's lips, ucbvax!mwm Than you or your finery." mwm@ucbjade.BITNET
franka@mmintl.UUCP (Frank Adams) (12/17/87)
In article <561@amethyst.ma.arizona.edu> chris@spock.ame.arizona.edu (Chris Ott) chris%spock@amethyst.UUCP writes: > One of the features of AOS/VS (Data General) that I like is its >variable element size. Files are made up of elements of a given number >of blocks. For example, if a file's element size is 10 blocks, the file >will grow in chunks of 10 blocks at a time. ... I haven't seen this feature >on any other operating system. Has anyone else? IBM's OS/MVS/whatever-they-want-to-call-it has this in spades. (You don't really *want* it in spades, but that's how they have it.) The increment size is specified not per file, but per open file. Actually, there is an underlying segment size, but new chunks of the file are allocated in units of the specified size. You also specify the initial size, which may be either smaller or larger than later chunks. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
peter@sugar.UUCP (Peter da Silva) (12/17/87)
In article <1971@cup.portal.com>, Mark_G_Woodruff@cup.portal.com writes: > From: uunet!nuchat!sugar!peter > > Berkeley symbolic links. > [Please explain.] You create a symbolic link from "/usr/joe/blah" to "/work/acct/fred/baz". The link is actually the string "/work/acct/fred/baz". > > VMS/AmigaDOS symbolic names. > [Please explain.] In AmigaDOS: 1> LIST SYS:C Directory "sys:c" on Wednesday 16-Dec-87 Run 2324 rwed Today 05:57:30 Fault 2728 rwed Today 05:57:30 Install 1800 rwed Today 05:57:31 ... 1> ASSIGN C: SYS:C 1> LIST C: Directory "c:" on Wednesday 16-Dec-87 Run 2324 rwed Today 05:57:30 Fault 2728 rwed Today 05:57:30 Install 1800 rwed Today 05:57:31 ... 1> ; You can do the same sort of thing under VMS. This does the same sort of job as links: creates an alias for a file. It has strong points and weak points. > > RMD in RSX. > [Please explain.] Realtime Memory Display. Shows processes and where they are in memory. The best memory display type setup I've ever seen. > > Being small and tight is good. Taking features out if it helps is good. > > Version 7 is a better designed O/S than either System V or Berkeley. This last cannot be too strongly emphasised. > From: Mark.G.Woodruff@Cup.Portal.Com > > o Virtual Machines. They allow you to code as close (or far) from the > hardware as you like without sacrificing security. They also aid > tremendously when writing operating systems or hardware-dependent > software. They also give you a performance hit. See above. > o A common command language for both the editor and the shell. With > Rexx and Xedit under VM, you can use the same command language to > write your editor macros and you shell scripts. This also makes the > editor a much more powerful tool for software building than any > equivalent under Unix. What about Emacs? > o An easy-to-learn command language. Rexx is far easier to learn and use > than any other interpreted language I've seen (including Basic, the > shell and cshell languages, Logo, and Smalltalk). None of which are really terribly easy to learn. > o An object-oriented file system. The designers of Unix made a serious > mistake in forcing all objects in their file system to have the same > format. A much better approach would be to define a common protocol, > then let each object decide how best to implement it. I'd have to see this in action. My experience with IBM file systems has been that they're like trying to read a menu in a dark restaurant wearing sunglasses. > o Long command and option names that can be abbreviated easily. Unix > is impossible for a novice to use without a manual in large part due > to its poor user interface in this regard. CMS is better??? > o A real-time kernal. Essential for a great many tasks. For a real-time machine, yes. For a time-shared machine, no. Personal computers should be real-time. Mainframes shouldn't be. > o Contiguous file allocation on large devices. The additional overhead > of discontiguous file allocation is unwarranted on modern hardware. How do you implement this without throwing away most of your file space to fragmentation and/or having the overhead of frequent garbage collection? > Mark In closing, I'd like to ask why you made this survey only to completely ignore most of it? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
kolding@cory.Berkeley.EDU (Eric Koldinger) (12/18/87)
In article <3228@tut.cis.ohio-state.edu> karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) writes: > One of the features of AOS/VS (Data General) that I like is its > variable element size. Files are made up of elements of a given number > of blocks. For example, if a file's element size is 10 blocks, the file > will grow in chunks of 10 blocks at a time... > ...I haven't seen this feature > on any other operating system. Has anyone else? > >Computer Consoles, Inc's PERPOS of a couple of years back supported >contiguous file creation. You had to give it the total size of the >file required, as I recall, no file growth once it's created. PERPOS >(a fault-tolerant UNIX derivative) was intended for a heavy >transaction-oriented system, which made this sort of use important. OS/360/370/SVS/MVS had this feature beat by years. When you create a file, a painful process at best, you specify ALL of it's attributes, such as logical record length, block size (yes, you set it yourself, not the system), whether or not records are of variable size, and the amount of space the file will take up. It even allows for a somewhat limited expansion of the file by allocating secondary extents which are allocated when the primary extent is filled up. However, you can only get 15 secondary extents and 1 primary one, so files can't grow forever, but with utilities the extents can be merged to allow more growth, but again this is a painful process (seems everything in MVS is painful, but maybe I just like Un*x too much). [Eat hot death line-counting scum!] _ /| Eric \`o_O' kolding@cory.berkeley.edu ( ) "Gag Ack Barf" {....}!ucbvax!cory!kolding U
irf@kuling.UUCP (Stellan Bergman) (12/18/87)
In article <1169@nmtsun.nmt.edu> hydrovax@nmtsun.nmt.edu (M. Warner Losh) writes: >This is a simple concept. When the user has typed in enough of the command >to make it unique and hits a specified key (usually ESCAPE in TOPS-20), the >rest of the command appears "by magic". This may be difficult to understand >from a unix point of view, since all of the commands are cryptic beyond >believe (they can be learned, but it is painful). In contrast the TOPS-20 No, it is not since I have exactly the same behavior on my HP-UX 'csh' (and also on the 'tcsh' on the VAX 4.2BSD I'm running at this moment. And the names are not fixed. The commands just happen to be invoked by default by the name of the file. These names are beautiful and not so little amusing therefore *easy* to remember. They may be changed very easily (see next comment of mine). >and VMS commands are long and verbose, allowing you to know EXACTLY (or >nearly so) what is going down. For example, on TOPS-20, to print a file >you type >@ PRint (file) Foo.txt /Copies:2 Again in my 'csh' or 'tcsh' I'd write : "alias p lp", "alias print lp" which would do a listing by either the single letter command 'p' or the full name command 'print'. But who would do such a stupid thing to replace 'lp' with 'print' and thereby wasting almost a second typing in superfluous letters :-). As I usually say: I'm giving my computers orders -- not writing novels... Any military officer knows that orders should be short and precise. Bo Thide', Swedish Institute of Space Physics UUCP: ...enea!kuling!irfu!bt
ok@quintus.UUCP (Richard A. O'Keefe) (12/18/87)
Concerning multiple-extent (dynamically allocated) contiguous files:
(1) The B6700 MCP provided multiple-extent files; very easy to use.
Oodles of things you could say, very little you had to.
(2) Doesn't VMS provide a feature like this?
(3) Most versions of UNIX don't provide such a feature,
but read appendix K of the POSIX book. (Anyone know what is
happening about this?)jesup@pawl22.pawl.rpi.edu (Randell E. Jesup) (12/18/87)
[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.
// 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)andy@rocky.STANFORD.EDU (Andy Freeman) (12/19/87)
In article <588@kuling.UUCP> irf@kuling.UUCP (Stellan Bergman) writes: >In article <1169@nmtsun.nmt.edu> hydrovax@nmtsun.nmt.edu (M. Warner Losh) writes: [explains how recognition works on TOPS-20] >No, it is not since I have exactly the same behavior on my HP-UX 'csh' (and >also on the 'tcsh' on the VAX 4.2BSD I'm running at this moment. No you don't have exactly the same behavior. You have recognition for command names and arguments that are file names. TOPS-20 command parser provides recognition for arguments that aren't file names as well as those that are. You can also ask it what arguments are legal. TOPS-20's command parser is also used by almost every native TOPS-20 program. How many unix programs have tcsh's (or 4.3BSD's csh's) recognition? There is a TOPS-20-like command parser for unix and using something that good will be common in 20 years. So what if TOPS-20 is about as old as unix and has had it for 10 years? Unix' superiority is that it is portable - it's not dead and TOPS-20 is. -andy ps - Getopt IS a big advance for unix, but in the grand unix tradition, it does too little and is probably subtly incompatible with what it is supposed to be patterned after. The former can be blamed on unix. -- Andy Freeman UUCP: {arpa gateways, decwrl, sun, hplabs, rutgers}!sushi.stanford.edu!andy ARPA: andy@sushi.stanford.edu (415) 329-1718/723-3088 home/cubicle
jefu@pawl21.pawl.rpi.edu (Jeffrey Putnam) (12/19/87)
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).
peter@sugar.UUCP (Peter da Silva) (12/20/87)
hydrovax@nmtsun.nmt.edu (M. Warner Losh) writes: > From what I have seen, it appears that the symbolic names (which > I read as logical names. Somebody correct me if I'm wrong) to > be a superset of enviornment symbols. Nope, because symbolic names are early-bound. Environment symbols are late-bound. You can't define a logical name for a file that doesn't exist at define time. Also, environment symbols are context-free: you don't have to have a filename there. For example, I use SET to define my path for include files instead of ASSIGN on the Amiga, because I may not have the include disk mounted during the boot process. The coimpiler knows about SET and pulls it out at run-time. Secondly (and more importantly), you can't define a logical name for such things as PATH and ROGUEOPTS, because they're not simple file names. I'd much rather have both. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (12/20/87)
In article <561@amethyst.ma.arizona.edu>, chris@spock (Chris Ott) writes: > One of the features of AOS/VS (Data General) that I like is its > variable element size. For example, if a file's element size is 10 blocks, > the file will grow in chunks of 10 blocks at a time. RSX 11 supports this. It's called the extend size. It's more convenient than the system you describes because you can also truncate the file down to the real size when disk space gets short. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
dag@chinet.UUCP (Daniel A. Glasser) (12/23/87)
In article <477@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >Concerning multiple-extent (dynamically allocated) contiguous files: > [deleted stuff] >(2) Doesn't VMS provide a feature like this? Yes, and so does RMS on RSX-11. Some DEC operating systems also have an attribute for "Conditionally contiguous", which will endevor to keep the file contiguous, but when there is no space available reverts to non-contiguous. -- Daniel A. Glasser ...!ihnp4!chinet!dag ...!ihnp4!mwc!dag ...!ihnp4!mwc!gorgon!dag One of those things that goes "BUMP!!! (ouch!)" in the night.
jesup@pawl11.pawl.rpi.edu (Randell E. Jesup) (12/28/87)
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)
jefu@pawl18.pawl.rpi.edu (Jeffrey Putnam) (01/01/88)
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
simon@its63b.ed.ac.uk (ECSC68 S Brown CS) (01/11/88)
In article <174@imagine.PAWL.RPI.EDU> userft4z%rpitsmts@itsgw.rpi.edu writes: > >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. [silly mode on...] Or the third way - use the manuals as they stand, and use an Incredibly Clever Program to consult them to find out what you want. For example, if I want to find out what a particular option to a command does, the ICP looks in the manual to find out what it does, and prints out a little paragraph descibing it. Or I could get it to print out a short summary of all possible options, or I could get it to tell me what's wrong with what I've done (when using something complex like awk or sed on a command-line, for instance). Just like "asking an expert"! Also, since the ICP is just a program, it could be used by any other program to do this sort of thing - not just the shell. So, you get automatic help for any program you like by just hooking in a few ICP calls. It could even be called *automatically* before actually giving your input to its target program, to do sanity-checking, so you could fix it easily without having to type very much at all: $ awk "complex-and-difficult-to-understand-expressions" < file --ICP: Oops, that's not going to work, you know, Simon! According to the "awk" manual: {desciption of why what I said was wrong} I suggest changing it to {something-else} Which of the following would you like to do? a) make the change I suggested b) edit the expression yourself (with $EDITOR) c) give up --? Or whatever kind of sickly user-smarmy interface you prefer to use.... :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) [...silly mode off] > >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. However, there's no reason why such things shouldn't be part of the operating system (or, more usefully, *appear* to be so). That's why the Logical-Names feature of VMS is such a big win - they're not restricted just to the command interpreter and those few other programs which happen to know about them, but are available anywhere (unlike "environment variables" in Unix). Something analagous to Streams, allowing user-definable interfaces to be installed on top of the bare system access-points (not system-calls; I'm thinking more of things like namei()) would be incredibly useful. I want to be able to use logical variables whenever I use filenames?- easy; I just push a namei-module that recognizes such things, then all processes I create will automatically be able to use them. In this way, all the junk that's crept into the shells can be taken out and re-implemented in a uniform way. --Simon -- -------------------------------------------------- | Simon Brown | | Laboratory for Foundations of Computer Science | | Department of Computer Science | | University of Edinburgh, Scotland, UK. | -------------------------------------------------- UUCP: uunet!mcvax!ukc!lfcs!simon ARPA: simon%lfcs.ed@nss.cs.ucl.ac.uk "Life's like that, you know" JANET: simon@uk.ac.ed.lfcs