From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: TOPS-20 command interpreter Date: Fri, 10 Dec 1999 00:01:25 -0600 Organization: MindSpring Enterprises Lines: 9 Message-ID: NNTP-Posting-Host: c7.ae.33.a4 X-Server-Date: 10 Dec 1999 05:58:47 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news-lei1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!newsfeed.mindspring.net.MISMATCH!news.mindspring.net!newsfeed.mindspring.net!firehose.mindspring.com!hshubs What can people tell me about this thing? I know it did command completion, and would respond to "?" with assistance, but what else? How was it done? Could you add commands to the system easily like on VMS? etc. -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: dpeschel@u.washington.edu (Derek Peschel) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 10 Dec 1999 12:04:21 GMT Organization: University of Washington, Seattle Lines: 51 Message-ID: <82qq85$p0s$1@nntp1.u.washington.edu> References: NNTP-Posting-Host: saul7.u.washington.edu X-Trace: nntp1.u.washington.edu 944827461 25628 (None) 140.142.17.37 X-Complaints-To: help@cac.washington.edu NNTP-Posting-User: dpeschel Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!enews.sgi.com!paloalto-snf1.gtei.net!news.gtei.net!newsfeed.stanford.edu!logbridge.uoregon.edu!news.u.washington.edu!dpeschel In article , Howard S Shubs wrote: >What can people tell me about this thing? > >I know it did command completion, and would respond to "?" with assistance, >but what else? How was it done? Could you add commands to the system easily >like on VMS? etc. The interpreter was designed to be very easy to use. I think it was one of the earliest implementations of command completion out there. (There was an earlier one, done at Berkeley on IIRC their SDS-940, which had the fatal flaw of completing automatically. This created great confusion when you didn't want it to complete. Often people would type an entire command, the shell would complete it after the first few characters, and the extra characters would then appear after the completion and be completed in turn.) The command completion feature depends heavily on a system call which does most of the work. Each invocation of the system call only parses the next chunk of the command line (up to the point where the user must make a decision) so there is a large data structure or two to hold the state across system calls. The data structures are actually a very important part of the parsing process; they define the entire tree of paths that lead from an empty command line to a full one. At each node, the user can choose one of the possible edges, thus leading to antoher node. The edges represent parts of the finished command line and can have different types (filename, number, string, "prompt" words which are always in parentheses, etc.) It is also possible to back up in the tree. A "?" prints out the list of tokens that may occur at the current point (though it's possible to suppress a token from the list, I think). An "esc" completes the current token. There are a few other keys which I forget. The shell could be extensible (since it's separate from the system call) but I don't think it is. BTW, this shell was the inspiration for csh and tcsh. Unfortunately I don't think the UNIX shells work as well. TOPS-20 has the advantages of a restricted character set and the intelligence in the parse tree. UNIX has a less restrictive "anything can go anywhere" syntax and the shell doesn't have much knowledge about the command being completed. (Yes, I know you can tell it things.) I am NOT convinced that having the shell do wildcard expansion IN ALL CASES is a good idea; there are times when it shouldn't be done (as when the wildcard expression refers to a bunch of files that don't yet exist). See the e-mail which I am also sending you. -- Derek ###### From: alderson@netcom2.netcom.com (Richard M. Alderson III) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 10 Dec 1999 19:36:45 GMT Organization: NETCOM On-line services Lines: 60 Message-ID: References: <82qq85$p0s$1@nntp1.u.washington.edu> Reply-To: alderson@netcom.com NNTP-Posting-Host: c7.b7.09.66 X-Server-Date: 10 Dec 1999 19:36:46 GMT In-reply-to: dpeschel@u.washington.edu's message of 10 Dec 1999 12:04:21 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!newsfeed.Austria.EU.net!peerbox.kpnqwest.net!blackbush.xlink.net!news0.de.colt.net!colt.net!news.maxwell.syr.edu!news.mindspring.net!firehose.mindspring.com!207.69.128.199!alderson In article <82qq85$p0s$1@nntp1.u.washington.edu> dpeschel@u.washington.edu (Derek Peschel) writes: >The command completion feature depends heavily on a system call which does >most of the work. Each invocation of the system call only parses the next >chunk of the command line (up to the point where the user must make a >decision) so there is a large data structure or two to hold the state across >system calls. The COMND% JSYS. Most JSYi are described in a page or two of text, the complex ones in four or five; COMND% takes up eighteen pages. >The data structures are actually a very important part of the parsing process; >they define the entire tree of paths that lead from an empty command line to >a full one. At each node, the user can choose one of the possible edges, >thus leading to antoher node. The edges represent parts of the finished >command line and can have different types (filename, number, string, >"prompt" words which are always in parentheses, etc.) It is also possible >to back up in the tree. >A "?" prints out the list of tokens that may occur at the current point >(though it's possible to suppress a token from the list, I think). An "esc" >completes the current token. There are a few other keys which I forget. Yes, items can be suppressed, such as defined abbreviations (say, "D" is short for "DEPOSIT" rather than "DELETE"). Without those, all commands would have to be entered up to unambiguity. The ESCape character completes a field including any following guide words, while ^F completes only the filed text itself. >The shell could be extensible (since it's separate from the system call) but >I don't think it is. Not "shell", "command interpreter", a program named EXEC. And it is extensible using PCL (Programmable Command Language), a rather BLISS-looking extension language created at CMU (so the appearnace isn't surprising). Not Turing- complete, but pretty handy, as it provides a way to create new COMND% entries in a running EXEC, which can then be saved. Or the PCL environment can be saved instead, to be loaded on demand. >BTW, this shell was the inspiration for csh and tcsh. Unfortunately I don't >think the UNIX shells work as well. TOPS-20 has the advantages of a >restricted character set and the intelligence in the parse tree. UNIX has a >less restrictive "anything can go anywhere" syntax and the shell doesn't >have much knowledge about the command being completed. (Yes, I know you can >tell it things.) I am NOT convinced that having the shell do wildcard >expansion IN ALL CASES is a good idea; there are times when it shouldn't be >done (as when the wildcard expression refers to a bunch of files that don't >yet exist). Indeed, having the command interpreter, whether Unix shell or Tops-20 EXEC, do wildcard expansion is a major source of lossage. Wildcard expansion should be handled by a system call in the program needing that facility; cf. GTJFN% and GNJFN% in Tops-20. Rich Alderson Last LOTS Tops-20 Systems Programmer, 1984-1991 Current maintainer, MIT TECO EMACS (v. 170) last name @ XKL dot COM Chief systems administrator, XKL LLC, 1998-now ###### From: alderson@netcom2.netcom.com (Richard M. Alderson III) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 10 Dec 1999 20:08:15 GMT Organization: NETCOM On-line services Lines: 112 Message-ID: References: Reply-To: alderson@netcom.com NNTP-Posting-Host: c7.b7.09.66 X-Server-Date: 10 Dec 1999 20:08:17 GMT In-reply-to: Howard S Shubs's message of Fri, 10 Dec 1999 00:01:25 -0600 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.mindspring.net!newsfeed.mindspring.net!firehose.mindspring.com!207.69.128.199!alderson In article Howard S Shubs writes: >What can people tell me about this thing? >I know it did command completion, and would respond to "?" with assistance, >but what else? How was it done? Could you add commands to the system easily >like on VMS? etc. VMS??? *Hxxx&k* ! Unlike VMS, typing "?" in the middle of a command did not interrupt entering the command to run the HELP program, but instead provided a text description of whatever was expected next on the command line, then re-typed the command up to the point of the "?" on the next line. Thus, if you needed to know the avail- able switches on a command, you might get something like !lwPRINT ? confirm with carriage return or input filespec !lwPRINT (Note that the change in case above is where I typed an ESCape for completion.) !lwPRINT login.cmd ? confirm with carriage return or printer selection or output handling specification, one of the following: /APPLE /ASIZE /BSIZE /DVIFILE /HP /MANUALFEED /NOPRINT /PANASONIC /POSTSCRIPT /REALTECH /REVERSE /SCREENVIEW /TEXTFILE /UNITNUMBER: or ASCII text processing switches, one of the following: /BORDER /BOTTOMMARGIN: /COLUMNS: /ENVELOPEADDRESS /FONTNAME: /FONTSIZE: /LANDSCAPE /LEFTMARGIN: /LETTERHEAD /OUTLINE /PAGENUMBERS /PORTRAIT /RFCFORMAT /RIGHTMARGIN: /SCRIBEMODE /TOPMARGIN: /TWOCOLUMN !lwPRINT login.cmd (This command, as it happens, was written in PCL (see my followup to Derek Peschel's message), thought it could have been done in Macro-20 in the sources to the EXEC.) Note the set of processing switches for ASCII text. Had this been a Postscript file (at least, if it had the file extension .PS or .PSF), a different set of options would have come up; had it been a .DVI file output by TeX, yet another set would appear. The following is what I get with a "?" at the empty EXEC prompt: !? Command, one of the following: ACCESS ADVISE APPEND ARCHIVE ASSIGN ATTACH BACKSPACE BLANK BREAK BUILD CANCEL CD CLOSE COMPILE CONNECT CONTINUE COPY CREATE CREF CSAVE DAYTIME DDT DEASSIGN DEBUG DECLARE DEFINE DELETE DEPOSIT DETACH DIRECTORY DISABLE DISCARD DISMOUNT DO ECHO EDIT ENABLE END-ACCESS EOF ERUN EXAMINE EXECUTE EXPUNGE FDIRECTORY FINGER FORK FREEZE GET HELP HISTORY INFORMATION KEEP KJOB KMIC LOAD LOGOUT LWPRINT MAIL MAP MERGE MODIFY MOUNT ORIGINAL POP PRESERVE PRINT PUSH QDIRECTORY R RDIRECTORY RECEIVE REDO REENTER REFUSE REMARK RENAME RESET RETRIEVE REWIND RUN SAVE SEND SET SKIP START SUBMIT SYSTAT TAKE TALK TDIRECTORY TERMINAL TRANSLATE TYPE UNATTACH UNDECLARE UNDELETE UNKEEP UNLOAD UNMAP UPDATE VDIRECTORY WDIRECTORY or kept fork name, one of the following: MM RMACS XMM or "^E" or system program name ! If I were not a WHEEL, with capabilities enabled, I would not see the line reading 'or "^E"', since the commands prefixed by ^E are privileged. Note that LWPRINT, my example above, appears in the standard list of commands even though it is an externally defined PCL procedure. Any executable program can be specified at the prompt; if it is written to the Tops-20 coding standard, it will use the COMND% JSYS for command parsing, so that the same features present in the EXEC will work in the user program. The effect of the Unix PATH environment variable is obtained by defining the logical name SYS:. !iNFORMATION (ABOUT) lOGICAL-NAMES (OF) ? one of the following: ALL JOB SYSTEM or logical name !iNFORMATION (ABOUT) lOGICAL-NAMES (OF) sys: Job-wide: sys: => DSK:,DASM:,RMACS:,MDL:,SYSTEM:,ADMIN:,1022:,SYS: System-wide: sys: => PS:,PS:,UNIX-SYS:,PS:,SYSTEM:,TEX:,GAME S:,UNS:,DSK: ! Note that the user's job-wide definition can include the system-wide definition by simply including SYS: in its own definition. The same is true for any job- wide logical name referring to a system-wide one. Hope that helps... Rich Alderson Last LOTS Tops-20 Systems Programmer, 1984-1991 Current maintainer, MIT TECO EMACS (v. 170) last name @ XKL dot COM Chief systems administrator, XKL LLC, 1998-now ###### From: siegman@stanford.edu (A. E. Siegman) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Fri, 10 Dec 1999 17:15:35 -0800 Organization: Stanford University Lines: 29 Message-ID: References: <385144CC.AAA55923@plano.net> NNTP-Posting-Host: siegmanpbook.stanford.edu X-Newsreader: MT-NewsWatcher 2.4.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news-fra.pop.de!news.csl-gmbh.net!blackbush.xlink.net!newsfeed.tli.de!newsfeed.berkeley.edu!newsfeed.stanford.edu!nntp.stanford.edu!siegman > When you typed enough of the command for the system to recoginize > which command you wanted, you pressed (I think), and the system would > complete typing the word and present you with "guide words" to assist with input. > > For example, you might type "cop" and the system would complete the line so > far as: > > copy (from file) > > leaving the curser after the parenthesized expression. Then you type a file name > and a space followed by , the system continued like this: > > copy (from file) foobar.txt (to file) > > leaving the cursor after the second parenthetical expression. I was an non-expert user of one of Stanford University's DEC-10 or DEC-20 computer systems way back then, and after using this incredibly helpful and sensible system for several years, I was totally unable to understand why the "improved" and "better" UNIX system that replaced the DEC-20s apparently couldn't do anything like the same thing. It wasn't a GUI, but it was a hell of a sensible, helpful, and usable approach for non-computer-experts, who just wanted to get useful things done on the system. ###### From: Charles Richmond Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Fri, 10 Dec 1999 18:22:04 +0000 Organization: Cannine Computer Center Lines: 47 Message-ID: <385144CC.AAA55923@plano.net> References: Reply-To: richmond@plano.net X-Complaints-To: newsabuse@supernews.com X-Mailer: Mozilla 4.03 (Macintosh; I; 68K) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newspeer.te.net!news.indigo.ie!news-out.cwix.com!newsfeed.cwix.com!newsfeed.berkeley.edu!remarQ70!rQdQ!supernews.com!remarQ.com!corp.supernews.com!not-for-mail Howard S Shubs wrote: > > What can people tell me about this thing? > > I know it did command completion, and would respond to "?" with assistance, > but what else? How was it done? Could you add commands to the system easily > like on VMS? etc. > In reading the other posts in this thread, I did *not* find a mention of "guide words". When you typed enough of the command for the system to recoginize which command you wanted, you pressed (I think), and the system would complete typing the word and present you with "guide words" to assist with input. For example, you might type "cop" and the system would complete the line so far as: copy (from file) leaving the curser after the parenthesized expression. Then you type a file name and a space followed by , the system continued like this: copy (from file) foobar.txt (to file) leaving the cursor after the second parenthetical expression. Or you could begin the comand by typing "copy", and the system would start the next line as: (from file) leaving the cursor after this parenthetical expression. You type the input file name and hit return. The system starts the next line as: (to file) leaving the cursor after this. You add the destination file name and hit return. The system had guide words for *all* the commands that were available. It is great for hand holding, and generally the words told you what you had to enter next. Of course, I am speaking from a user point of view (as remembered from doing this 20 years ago). I have *no* knowledge at all about implementation details. -- +-------------------------------------------------------------+ | Charles and Francis Richmond | +-------------------------------------------------------------+ ###### Newsgroups: alt.folklore.computers From: svm@kozmix.ow.nl (Sander van Malssen) Subject: Re: TOPS-20 command interpreter X-Newsreader: trn 4.0-test72 (19 April 1999) Reply-To: svm@kozmix.ow.nl Sender: svm@kozmix.ow.nl (Sander van Malssen) Organization: Kozmic Egg Productions, The Hague, Netherlands Message-ID: References: Date: Fri, 10 Dec 1999 20:44:20 GMT Lines: 22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!news-feed.inet.tele.dk!bofh.vszbr.cz!newsgate.cistron.nl!news.cistron.nl!kozmix!not-for-mail alderson@netcom.com writes: > In article Howard S Shubs > writes: > > >I know it did command completion, and would respond to "?" with > >assistance, but what else? How was it done? Could you add commands > >to the system easily like on VMS? etc. > > VMS??? *Hxxx&k* ! > > [descripton snipped] I think that those interested could get a pretty good idea of how this kind of command line interface works by firing up a copy of the Kermit comms program (at least the C-Kermit, at any rate) and see what happens when you type escapes and question marks at it. Cheers, Sander -- Sander van Malssen -- svm@kozmix.ow.nl -- http://svm.www.cistron.nl/ ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Fri, 10 Dec 1999 21:44:15 -0600 Organization: MindSpring Enterprises Lines: 13 Message-ID: References: <385144CC.AAA55923@plano.net> <82sa1d$iec$1@nntp1.u.washington.edu> NNTP-Posting-Host: c7.ae.38.a6 X-Server-Date: 11 Dec 1999 03:44:15 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news-koe1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!hshubs In article <82sa1d$iec$1@nntp1.u.washington.edu>, dpeschel@u.washington.edu (Derek Peschel) wrote: >The program that is going to use the command line builds a detailed >description of everything that can occur at various points. These "things >that can occur" include numbers, filenames, command words, and guide words. Was it done with something like a VMS .CLD file? Note: I've never paid much attention to BLISS, so I wouldn't know if something looked like it. -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Fri, 10 Dec 1999 21:49:16 -0600 Organization: MindSpring Enterprises Lines: 15 Message-ID: References: NNTP-Posting-Host: c7.ae.38.a6 X-Server-Date: 11 Dec 1999 03:49:16 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!newsfeed.arcor-ip.de!newsfeed.nacamar.de!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!hshubs In article , alderson@netcom.com wrote: >Any executable program can be specified at the prompt; if it is written to >the >Tops-20 coding standard, it will use the COMND% JSYS for command parsing, so >that the same features present in the EXEC will work in the user program. Do you mean that the command interpretor called the program being invoked to help with hinting the command line? Kinda like a callback, but in reverse: a callforward. -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Fri, 10 Dec 1999 21:50:42 -0600 Organization: MindSpring Enterprises Lines: 15 Message-ID: References: NNTP-Posting-Host: c7.ae.38.a6 X-Server-Date: 11 Dec 1999 03:50:42 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!news-peer-europe.sprintlink.net!news.sprintlink.net!news.algonet.se!algonet!newsfeed.icl.net!iol.ie!news-MUC.ecrc.net!news-FFM2.ecrc.net!news.mindspring.net!firehose.mindspring.com!hshubs In article , tsmurphy@students.uiuc.edu (Terry Murphy) wrote: >I'm unfortunately too young to have experienced it, and I ALMOST missed >VMS as well. Is there any way at all to see what it looks like? Through >emulators? I suppose the DEC-20 hardware is a lot more rare than VAX >hardware. I saw one run, and then crash hard due to a hardware fault, as recently as 1997. This was an actual DECSYSTEM-20, not a desktop box of any sort. There may still be stubborn people out there running them. -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Fri, 10 Dec 1999 21:51:23 -0600 Organization: MindSpring Enterprises Lines: 12 Message-ID: References: NNTP-Posting-Host: c7.ae.38.a6 X-Server-Date: 11 Dec 1999 03:51:27 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!firehose.mindspring.com!hshubs In article , svm@kozmix.ow.nl wrote: >I think that those interested could get a pretty good idea of how this >kind of command line interface works by firing up a copy of the Kermit >comms program (at least the C-Kermit, at any rate) and see what happens >when you type escapes and question marks at it. That's right, IIRC Kermit was originally designed under TOPS-20, yes? -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Sat, 11 Dec 1999 01:18:47 -0600 Organization: MindSpring Enterprises Lines: 92 Message-ID: References: <82snub$l8s$1@nntp1.u.washington.edu> NNTP-Posting-Host: c7.ae.36.b4 X-Server-Date: 11 Dec 1999 07:18:51 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!howland.erols.net!newsfeed.mindspring.net.MISMATCH!news.mindspring.net!firehose.mindspring.com!hshubs In article <82snub$l8s$1@nntp1.u.washington.edu>, dpeschel@u.washington.edu (Derek Peschel) wrote: >In article , >Howard S Shubs wrote: >> Do you mean that the command interpretor called the program being >>invoked to help with hinting the command line? Kinda like a callback, but >>in >>reverse: a callforward. > >I'm looking forward to what Rich has to say, since I am very confused about >this particular issue. But I don't think so. > >There are two possibilities: > >1) EXEC contains the data for parsing the command line of a particular >program. I mean that the data is actually part of EXEC itself. You can >then build up a command line, with EXEC's help. I'm not sure what the >program does to access the command line that has been built up this way. That seems to be the case, similar to DCLTABLES under VMS but more static as I can change DCLTABLES w/o reloading the system. >2) EXEC does not contain the data. You can't build up a command line before >you run the program. > >If I type > > filddt ? > >I simply get > > filddt ? Data line to be sent to program > filddt > >(FILDDT is a "file" version of the DDT debugger; it lets you read files into >memory and then modify them just like DDT modifies actual memory.) > >But once FILDDT starts, it gives me a FILDDT> prompt. Then it uses the same >command-parsing routines as the EXEC to parse its own little set of internal >commands. I can use ESC to complete words, ? to ask "what's next?", etc. That'd be how it works now, I think. >Or I suppose you could have another type of program, which gets a command >line from the shell and parses it in the standard way, but non- >interactively. This would be more like a typical C program, or actually >like MS-DOS where the program starts with the raw text of the command line. >But the routines to turn that raw text into useful information are shared by >all programs. I'm thinking of a, as I say in a later paragraph (why write sequentially? Just because it's easier to -read-???), special program section which would describe the command line options for a program AS PART OF the program. Too much overhead? Hm. Would mean the CLI would have to open the image before the line is terminated, as soon as a separator is seen from the command name. >What Rich said sounds like 2). And I didn't contradict what he said. He >didn't say anything about when the program is called. I think you made a >few UNIX-ish assumptions here. Unlikely. If I'm anything, I'm a VMS bigot, but I'm not very devout these days. I was raised on VMS before I saw TOPS-20, which I only used briefly and never programmed it at all. UNIX is a recent addition for me. >I could be wrong about all this -- the program could be called as the >command line is being built up, I suppose. But I doubt it. I suspect you're right. I wonder if that'd be a better way to do it, though. Wouldn't have to rebuild EXEC (kernel?), wouldn't have to deal with DCLTABLES. It'd be as simple as rebuilding the individual program involved and making sure the resultant image is in the path (or whatever). After all, when a program is loaded, the system has to get basic information from the image to know how/where to load it anyway. Why not have CLI information for invoking the program as part of the image? In VMS parlayance, it could be Yet Another PSECT, for this purpose only: a read-only data section with a given name. I've been thinking of trying to come up with a Better Command Interpreter; that's why I asked the question about TOPS-20 in the first place, as it has some of the neatest features. DCL is good, IMO, but I'm told by an extremely reliable source that it can not be modified to do this (command completion, built-in HELP). Fine. Start over. VMS needs an alternative CLI. DCL is not the alter at which VMS bows, POSIX not withstanding. -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: dpeschel@u.washington.edu (Derek Peschel) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 11 Dec 1999 01:39:57 GMT Organization: University of Washington, Seattle Lines: 109 Message-ID: <82sa1d$iec$1@nntp1.u.washington.edu> References: <385144CC.AAA55923@plano.net> NNTP-Posting-Host: saul9.u.washington.edu X-Trace: nntp1.u.washington.edu 944876397 18892 (None) 140.142.17.39 X-Complaints-To: help@cac.washington.edu NNTP-Posting-User: dpeschel Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newspeer.te.net!news.indigo.ie!news-out.cwix.com!newsfeed.cwix.com!logbridge.uoregon.edu!news.u.washington.edu!dpeschel In article <385144CC.AAA55923@plano.net>, Charles Richmond wrote: >Howard S Shubs wrote: >> What can people tell me about this thing? >> >> I know it did command completion, and would respond to "?" with assistance, >> but what else? How was it done? Could you add commands to the system easily >> like on VMS? etc. >> >In reading the other posts in this thread, I did *not* find a mention of >"guide words". When you typed enough of the command for the system to recoginize >which command you wanted, you pressed (I think), and the system would >complete typing the word and present you with "guide words" to assist with input. I mentioned them in my post when I wrote: : The edges represent parts of the finished :command line and can have different types (filename, number, string, :"prompt" words which are always in parentheses, etc.) But that's rather deeply buried in the middle of a paragraph. > >For example, you might type "cop" and the system would complete the line so >far as: > >copy (from file) > >leaving the curser after the parenthesized expression. Then you type a file name >and a space followed by , the system continued like this: > >copy (from file) foobar.txt (to file) > >leaving the cursor after the second parenthetical expression. > >Or you could begin the comand by typing "copy", and the system would start the >next line as: > >(from file) > >leaving the cursor after this parenthetical expression. You type the input file >name and hit return. The system starts the next line as: > >(to file) > >leaving the cursor after this. You add the destination file name and hit return. > >The system had guide words for *all* the commands that were available. It is >great for hand holding, and generally the words told you what you had to enter next. Good explanation! I don't know if I've seen the "guide words pop up on next line" feature before. This is one of the things that VMS borrowed from TOPS-20. IMO it got ruined in the transition; the VMS version looks ugly and is not universal. The VMS people tried to have the DCL command- processing code Do Everything (tm) -- as a result it's too confusing to understand (at least for me). One thing about TOPS-20: I know the guide words can be left out sometimes, but it could be that in certain cases they must appear. This creates long command lines. >Of course, I am speaking from a user point of view (as remembered from doing this >20 years ago). I have *no* knowledge at all about implementation details. The program that is going to use the command line builds a detailed description of everything that can occur at various points. These "things that can occur" include numbers, filenames, command words, and guide words. So the COPY command might accept command lines like these: COPY COPY (FROM FILE) COPY COPY (TO FILE) COPY (FROM FILE) (TO FILE) Where it says or you would type the actual name of a file, or a wildcard specification for a bunch of files. Everything else is typed as it is. The beauty of declaring a list of the legal command lines is that the computer can help you, by looking at the list. It knows what you've typed so far, and it can read the list and say, "Oh, a file name is supposed to go here." The guide words appear on the list in exactly the same way. (OK, I lied -- it's not a list, it's a tree, as I said in my other post. But if you're not worried about the programming details then that's just a piece of trivia.) You're right -- there are guide words for all (or most of) the commands. That's because the authors put them there. I think the command interpreter has internal trees about the internal commands, but any external program that wants to read its own command lines can create its own trees. I *think* (but I'm not sure) that the log-in program uses these routines. It can be written in a few different ways: LOGIN And there may be a version with guide words. It's smart enough to not print your password, even though that's still part of the command line. -- Derek ###### From: tsmurphy@students.uiuc.edu (Terry Murphy) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 11 Dec 1999 02:25:25 GMT Organization: University of Illinois at Urbana-Champaign Lines: 13 Message-ID: References: NNTP-Posting-Host: ux4.cso.uiuc.edu User-Agent: slrn/0.9.5.6 (UNIX) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!newsfeed.Austria.EU.net!newscore.univie.ac.at!howland.erols.net!vixen.cso.uiuc.edu!tsmurphy Richard M. Alderson III wrote: >VMS??? *Hxxx&k* ! What are some of the advantages/differences of TOPS-20 over VMS? Also what was the time frame for TOPS-20, compared to VMS? I'm unfortunately too young to have experienced it, and I ALMOST missed VMS as well. Is there any way at all to see what it looks like? Through emulators? I suppose the DEC-20 hardware is a lot more rare than VAX hardware. -- Terry ###### From: dpeschel@u.washington.edu (Derek Peschel) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 11 Dec 1999 05:17:09 GMT Organization: University of Washington, Seattle Lines: 32 Message-ID: <82smol$ov2$1@nntp1.u.washington.edu> References: <385144CC.AAA55923@plano.net> <82sa1d$iec$1@nntp1.u.washington.edu> NNTP-Posting-Host: saul9.u.washington.edu X-Trace: nntp1.u.washington.edu 944889429 25570 (None) 140.142.17.39 X-Complaints-To: help@cac.washington.edu NNTP-Posting-User: dpeschel Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!sunqbc.risq.qc.ca!newsfeed.berkeley.edu!news.u.washington.edu!dpeschel In article , Howard S Shubs wrote: >In article <82sa1d$iec$1@nntp1.u.washington.edu>, dpeschel@u.washington.edu >(Derek Peschel) wrote: >>The program that is going to use the command line builds a detailed >>description of everything that can occur at various points. These "things >>that can occur" include numbers, filenames, command words, and guide words. > >Was it done with something like a VMS .CLD file? Note: I've never paid much >attention to BLISS, so I wouldn't know if something looked like it. Rich mentioned PCL. Let's forget about PCL for a moment. Without PCL, the data structure that will be used at parsing time is simply embedded in the source code of the program. (This is a bit clumsy... but not as clumsy as it could be, if you have the MACRO assembler which can do a lot of the grunt work of creating complex data structures.) Our library has a book on beginning TOPS-20 assembly language. There's an example of this, I think. I could probably find it soon. So that means that EXEC has to know about all the commands it's going to run if it wants to parse their command lines. If you think about that, it can't be any other way. It would be nice if the data came from somewhere else, though. Then you wouldn't have to keep reassembling EXEC. And that's where PCL comes in. You could think of its files as like .CLD files, even though they might look different and do slightly different things. But not everything used them. I'm not sure the comparison is completely accurate since I don't know all the things PCL does. -- Derek ###### From: dpeschel@u.washington.edu (Derek Peschel) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 11 Dec 1999 05:37:15 GMT Organization: University of Washington, Seattle Lines: 58 Message-ID: <82snub$l8s$1@nntp1.u.washington.edu> References: NNTP-Posting-Host: saul9.u.washington.edu X-Trace: nntp1.u.washington.edu 944890635 21788 (None) 140.142.17.40 X-Complaints-To: help@cac.washington.edu NNTP-Posting-User: dpeschel Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!newsfeed.berkeley.edu!news.u.washington.edu!dpeschel In article , Howard S Shubs wrote: >In article , alderson@netcom.com >wrote: >>Any executable program can be specified at the prompt; if it is written to >>the >>Tops-20 coding standard, it will use the COMND% JSYS for command parsing, so >>that the same features present in the EXEC will work in the user program. > > Do you mean that the command interpretor called the program being >invoked to help with hinting the command line? Kinda like a callback, but in >reverse: a callforward. I'm looking forward to what Rich has to say, since I am very confused about this particular issue. But I don't think so. There are two possibilities: 1) EXEC contains the data for parsing the command line of a particular program. I mean that the data is actually part of EXEC itself. You can then build up a command line, with EXEC's help. I'm not sure what the program does to access the command line that has been built up this way. 2) EXEC does not contain the data. You can't build up a command line before you run the program. If I type filddt ? I simply get filddt ? Data line to be sent to program filddt (FILDDT is a "file" version of the DDT debugger; it lets you read files into memory and then modify them just like DDT modifies actual memory.) But once FILDDT starts, it gives me a FILDDT> prompt. Then it uses the same command-parsing routines as the EXEC to parse its own little set of internal commands. I can use ESC to complete words, ? to ask "what's next?", etc. Or I suppose you could have another type of program, which gets a command line from the shell and parses it in the standard way, but non- interactively. This would be more like a typical C program, or actually like MS-DOS where the program starts with the raw text of the command line. But the routines to turn that raw text into useful information are shared by all programs. What Rich said sounds like 2). And I didn't contradict what he said. He didn't say anything about when the program is called. I think you made a few UNIX-ish assumptions here. I could be wrong about all this -- the program could be called as the command line is being built up, I suppose. But I doubt it. -- Derek ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Sat, 11 Dec 1999 09:59:28 -0600 Organization: MindSpring Enterprises Lines: 43 Message-ID: References: <82snub$l8s$1@nntp1.u.washington.edu> <944955562.883929@shelley.paradise.net.nz> NNTP-Posting-Host: c7.ae.35.e0 X-Server-Date: 11 Dec 1999 15:59:29 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news0.de.colt.net!colt.net!iol.ie!news-MUC.ecrc.net!news-FFM2.ecrc.net!news.mindspring.net!newsfeed.mindspring.net!firehose.mindspring.com!hshubs In article <944955562.883929@shelley.paradise.net.nz>, don@news.daedalus.co.nz (Don Stokes) wrote: >As far as I can make out, the only reason DCL "can't" be modified to do >command completion is because nobody in DEC^H^H^HCompaq understands the >code. Who wrote it? Maybe we can get him/her up against a wall and get them to explain it in detail. >As the original author of this beastie, I must say that it's a truly >ugly hack perpetrated primarily because some damned fool told me it >couldn't be done. Been there. To win a bet, I implemented a doubly linked list using VAX FORTRAN. It -worked- but I wouldn't consider it -good-, or useful. >The DCL source is pretty hard to read, and is a fairly closed box. I'm >afraid it's one of my least favourite pieces of VMS; it's ugly, and it's >horrendously slow. The command table handling is a good idea, but >implemented badly -- it has only a single command table, so if you want >to add a new command in a session, it copies the entire (shared) >installed table into a private (non-shared) copy and adds the new >command to that. The new table is not propagated to subproceses. Yes, having modified DCLTABLES very often I'm aware of its problems from an external point-of-view. It seems to me that something -like- that could be used to do syntax-level HELP and command completion, but I'm not sure I like its monolithicity (hey, new word!). >The >internals of DCL are simply awful. Basically, if you think it looks >ugly on the outside (and I do), you ain't seen nothin' 'til you see the >inside... That's Yet Another Reason To Write Another CLI, IMHO. -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: jmfbahciv@aol.com Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Sat, 11 Dec 99 12:34:58 GMT Organization: UltraNet Communications, Inc. Lines: 27 Message-ID: <82tl55$c7j$2@autumn.news.rcn.net> References: X-Trace: go/dpCAmlcPH1cz0AMXuAuIl/t0Zq4WKEJdjz/zwVLs= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 11 Dec 1999 13:55:49 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newsmaster-01.vbs.at!newsrouter.chello.at!news-MUC.ecrc.net!netnews.com!feed1.news.rcn.net!rcn!207-172-216-240 In article , alderson@netcom2.netcom.com (Richard M. Alderson III) wrote: >In article Howard S Shubs > writes: > >>What can people tell me about this thing? > >>I know it did command completion, and would respond to "?" with assistance, >>but what else? How was it done? Could you add commands to the system easily >>like on VMS? etc. > >VMS??? *Hxxx&k* ! ROTFLMAO!! I couldn't have put it any better way. I never saw that particular sound effect spelled out. /BAH Subtract a hundred and four for e-mail. ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 11 Dec 1999 12:42:42 GMT Organization: Daedalus Consulting Lines: 30 Message-ID: <944955562.883929@shelley.paradise.net.nz> References: <82snub$l8s$1@nntp1.u.washington.edu> NNTP-Posting-Host: shelley.paradise.net.nz X-Trace: titan.xtra.co.nz 944916162 13392467 203.96.152.26 (11 Dec 1999 12:42:42 GMT) X-Complaints-To: abuse@xtra.co.nz NNTP-Posting-Date: 11 Dec 1999 12:42:42 GMT Cache-Post-Path: shelley.paradise.net.nz!unknown@203-96-144-16.cable.paradise.net.nz X-Cache: nntpcache 2.3.3b4 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed2.news.luth.se!luth.se!newsfeed.berkeley.edu!su-news-hub1.bbnplanet.com!lsanca1-snf1!news.gtei.net!news.netgate.net.nz!news.xtra.co.nz!don Howard S Shubs wrote: >some of the neatest features. DCL is good, IMO, but I'm told by an extremely >reliable source that it can not be modified to do this (command completion, As far as I can make out, the only reason DCL "can't" be modified to do command completion is because nobody in DEC^H^H^HCompaq understands the code. Anyone who's played with DCLCOMPLETE knows that it's perfectly possible to add comand/file completion and help to DCL, because this is precisely what DCLCOMPLETE does. As the original author of this beastie, I must say that it's a truly ugly hack perpetrated primarily because some damned fool told me it couldn't be done. (And on the Alpha it may well not be possible to repeat the hack that grafts the thing into DCL, but if one were allowed to modify the DCL source code, that wouldn't be necessary.) The DCL source is pretty hard to read, and is a fairly closed box. I'm afraid it's one of my least favourite pieces of VMS; it's ugly, and it's horrendously slow. The command table handling is a good idea, but implemented badly -- it has only a single command table, so if you want to add a new command in a session, it copies the entire (shared) installed table into a private (non-shared) copy and adds the new command to that. The new table is not propagated to subproceses. The internals of DCL are simply awful. Basically, if you think it looks ugly on the outside (and I do), you ain't seen nothin' 'til you see the inside... -- don ###### From: Howard S Shubs Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: Sat, 11 Dec 1999 22:01:29 -0600 Organization: MindSpring Enterprises Lines: 14 Message-ID: References: <944955562.883929@shelley.paradise.net.nz> <944996581.935955@shelley.paradise.net.nz> NNTP-Posting-Host: c7.ae.34.ed X-Server-Date: 12 Dec 1999 04:01:29 GMT User-Agent: MT-NewsWatcher/3.0 (PPC) X-Face: "S"r{U%bs].&Ud}Pc~~~0a]M:t5l>>EN\1Faw10M9NK1Xq59wo7-"s0S+[{etQorO /Nf-Ci"i9v'MT!R8)J]N[4|2&x1r^Iq&{SB"6dknr0=+6UFb.>+{zMn_1=rw&/V+"d@* ZS5\LoW_ Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!news.unisource.nl!news1.kpn.net!134.222.90.2.MISMATCH!EU.net!howland.erols.net!newsswitch.lcs.mit.edu!remarQ-easT!remarQ.com!supernews.com!news.mindspring.net!newsfeed.mindspring.net!firehose.mindspring.com!hshubs In article <944996581.935955@shelley.paradise.net.nz>, don@news.daedalus.co.nz (Don Stokes) wrote: >I think the CLI horse has well and truly bolted. There are some good >ideas in DCL -- the lexical functions and expressions are far superior >to Bourne shell facilities, and the idea of global command tables is >a good one, even if the implementation is truly appalling. So maybe what is needed is an insider to... rearrange things... in order to make this simpler, and then to use it to make an example. -- Howard S Shubs hshubs@mindspring.com hshubs@bix.com The Denim Adept Is this the right room for an argument? SPAM: uce@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1] ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 12 Dec 1999 00:06:22 GMT Organization: Daedalus Consulting Lines: 80 Message-ID: <944996581.935955@shelley.paradise.net.nz> References: <944955562.883929@shelley.paradise.net.nz> NNTP-Posting-Host: shelley.paradise.net.nz X-Trace: titan.xtra.co.nz 944957182 13444688 203.96.152.26 (12 Dec 1999 00:06:22 GMT) X-Complaints-To: abuse@xtra.co.nz NNTP-Posting-Date: 12 Dec 1999 00:06:22 GMT Cache-Post-Path: shelley.paradise.net.nz!unknown@203-96-144-16.cable.paradise.net.nz X-Cache: nntpcache 2.3.3b4 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!newsfeed.Austria.EU.net!peerbox.kpnqwest.net!EU.net!news.maxwell.syr.edu!news-feed1.tiac.net!cam-news-hub1.bbnplanet.com!lsanca1-snf1!news.gtei.net!news.netgate.net.nz!news.xtra.co.nz!don Howard S Shubs wrote: >don@news.daedalus.co.nz (Don Stokes) wrote: >>As far as I can make out, the only reason DCL "can't" be modified to do >>command completion is because nobody in DEC^H^H^HCompaq understands the >>code. > >Who wrote it? Maybe we can get him/her up against a wall and get them to >explain it in detail. Dave Cutler, originally. It's been hacked over by quite a lot of people, but the basic structure of DCL is Cutler's. It kinda feels (to me) like something that was tossed together in a hurry with the intention of coming back to it later, 'cept that never happened. >>The >>internals of DCL are simply awful. Basically, if you think it looks >>ugly on the outside (and I do), you ain't seen nothin' 'til you see the >>inside... > >That's Yet Another Reason To Write Another CLI, IMHO. VMS CLIs unfortunately are difficult things to write, for several reasons. They run in supervisor mode, which is a kind of no-mans land between exec mode and user mode -- you can't allocate process pool from super mode as you can from exec, and the supervisor stack is fixed size (unlike the user stack, which gets cleaned up during image rundown). You can't load user libraries, so ecerything you do has to be carried around with you if it's not available via system services. Secondly, DCL contains a bunch of callbacks, which things like LIB$SET_SYMBOL, LIB$SET_LOGICAL and friends use to call the CLI to set CLI-level environment stuff. Lots of stuff will not run without these callbacks working "properly". This interface isn't well documented. LIB$SPAWN, LIB$ATTACH and friends all use this interface. Included in the list of things handled in the CLI is all of the command parsing stuff; the CLI$ routines are just front-ends to SYS$CLI, which calls DCL to do the actual work. Not many VMS utilities will work without this stuff being present... Spawning CLI commands is tremendously ugly. The VMS process creation service has no way to pass a command to the newly created process, so what DCL does is create a mailbox, assigns the $CREPRC error parameter (ie SYS$ERROR:) to it, and sets the image parameter to be DCL itself. It then stuffs the command, plus DCL symbols and supervisor-mode process logicals (if required) and other odd bits of housekeeping information, down the mailbox. Once DCL has enough marbles to execute the command, it closes SYS$ERROR and reassigns it to the output file. That's why LIB$SPAWN has no error-file parameter to go with input-file (SYS$INPUT:) and output-file (SYS$OUTPUT:). I *think* one could write a decent CLI that co-existed with DCL. It would be kinda ugly getting it loaded -- if you wanted to specify it as your CLI you'd have to load DCL explicitly (which is ugly in itself; loading CLIs means loading the CLI once into P0 space to find out how big it is and therefore where to put it in the push-down P1 space, and then actually load it into P1). Basically, the CLI interface in VMS is a half-assed attempt to provide for loadable CLIs, foiled by a whole bunch of stuff that should really be either in user-mode libraries, supported in some kind of CLI support libraries, or supported in the kernel. I have been *so* tempted to add more CLI-type stuff into DCLCOMPLETE (and in fact Ray Curiel's mods to DCLCOMPLETE do that to a small degree with ">" redirection etc), but (a) it would have been a *lot* of work, and (b) everything DCLCOMPLETE does uses up non-shared and statically allocated process pool space. Note that the Posix stuff and earlier unix shell lookalikes for VMS tended to operate as separate processes. Doing this on VMS is slow; process creation is hard work for VMS, particularly when it has to haul in DCL as well (which it does if you want to execute CLI commands). It's been said that the single worst thing you can do to a VMS system is log in... I think the CLI horse has well and truly bolted. There are some good ideas in DCL -- the lexical functions and expressions are far superior to Bourne shell facilities, and the idea of global command tables is a good one, even if the implementation is truly appalling. -- don ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: TOPS-20 command interpreter Date: 12 Dec 1999 05:59:20 GMT Organization: Daedalus Consulting Lines: 19 Message-ID: <945017759.232308@shelley.paradise.net.nz> References: <944996581.935955@shelley.paradise.net.nz> NNTP-Posting-Host: shelley.paradise.net.nz X-Trace: titan.xtra.co.nz 944978360 13383920 203.96.152.26 (12 Dec 1999 05:59:20 GMT) X-Complaints-To: abuse@xtra.co.nz NNTP-Posting-Date: 12 Dec 1999 05:59:20 GMT Cache-Post-Path: shelley.paradise.net.nz!unknown@203-96-144-16.cable.paradise.net.nz X-Cache: nntpcache 2.3.3b4 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newscore.gigabell.net!dca1-hub1.news.digex.net!intermedia!cyclone.pbi.net!131.119.28.147!su-news-hub1.bbnplanet.com!lsanca1-snf1!news.gtei.net!news.netgate.net.nz!news.xtra.co.nz!don Howard S Shubs wrote: >don@news.daedalus.co.nz (Don Stokes) wrote: >>I think the CLI horse has well and truly bolted. There are some good >>ideas in DCL -- the lexical functions and expressions are far superior >>to Bourne shell facilities, and the idea of global command tables is >>a good one, even if the implementation is truly appalling. > >So maybe what is needed is an insider to... rearrange things... in order to >make this simpler, and then to use it to make an example. Fixing the CLI interface would be a *lot* of work (more than could reasonably be done under the radar), and not really worth it for an OS that's pretty close to the end of its economic life anyway. Adding new features to DCL as it stands wouldnt be terribly difficult (given access to the source) -- it'd be more difficult than adding to user-mode code, but well inside what a competant internals programmer should be able to deal with. -- don ###### Newsgroups: alt.folklore.computers From: mbg@world.std.com (Megan) Subject: Re: TOPS-20 command interpreter Message-ID: Date: Sat, 18 Dec 1999 00:53:18 GMT References: <833ifj$ae@gap.cco.caltech.edu> Organization: The World Public Access UNIX, Brookline, MA Lines: 46 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newspeer.te.net!news.indigo.ie!news-out.cwix.com!newsfeed.cwix.com!newsswitch.lcs.mit.edu!world!mbg drifkind@acm.deleteme.org (David Rifkind) writes: >>Hmm, it might be that the K is from KL-10, remembering the story from >>years ago. >The K was from Kermit. According to Frank da Cruz, they spent a little >time trying to back-form an acronym from the name, but never found a >good one. Named after the Muppets character, and originally developed >for DEC-20, IBM 370, CP/M, and MS-DOS. (Simultaneously. Kermit wasn't >intended for modem communication so much as file transfer between >systems that wouldn't talk to each other any other way.) I remember using KERMIT very early in its life... Somewhere I have a printed out document of the protocol... and the documentation. Yes, they apparently did use KERMIT as the name, working hard to find an acronym which would fit... The closest I can remember is K(L-10) E(rror-free) R(eciprocal) MIT(?) I'll have to see if I can find that printout... Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+ p.s. Kermit actually came out after a similar program (VTERM) was written for RT-11. Someone decided to keep the protocol proprietary, otherwise we might have had many versions of TRANSF (the peer for VTERM) instead of KERMIT... As itw as, there was a version for RT-11, RSTS, RSX/RTEM, TOPS-10 and TOPS-20. But even this program was pre-dated by a program called RAMCOM written by a student at WPI for pdp-10 to pdp-11 communications (if you read this, Hi Marc).