RCONN@Simtel20.ARPA@sri-unix.UUCP (07/20/84)
From: Richard Conn <RCONN@Simtel20.ARPA> Well, the new feature (actually, utility pair) is in place, and it works quite nicely. I thought I'd describe the concept to you and see what people think about it. ZCPR3 supports a concept (taken from AT&T's UNIX) which I call shells. The UNIX shell accepts a command line, interprets it, suspends itself and allows the command line to execute, and then resumes. The ZCPR3 shell, since we have a single-process (simple) OS, simply accepts a command line, interprets it, terminates (leaving messages about as to how ZCPR3 CP should reinvoke it) and allows the command line to execute, and then is resumed by the ZCPR3 CP. The bottom line is that, once a shell is running, whenever the ZCPR3 CP would print its prompt (DU:DIR>, like the CP/M D> prompt), the shell runs instead (no prompt appears from the ZCPR3 CP), and whatever the shell does becomes the user's interface to his system. Shells can be nested up to N levels deep (I recommend 4), so one shell can run another can run another ... . Examples of supplied ZCPR3 shells are MENU (which prints a menu and allows the user to select a menu item with a single keystroke), VFILER (which shows a file directory, allows the user to move the cursor around and manipulate files [copy, delete, rename, etc]), VMENU (which is a cross between VFILER [with the directory display and arrow] and MENU [with the menu display and selection]), and SH (which allows named variable sets and substitution in various forms). The new SHSET command (which is ONLY 1K in size) now exists and it allows ANYTHING to become a shell, whether is knows about ZCPR3 or not. The syntax is: SHSET cmd1;cmd2;... and, like a shell, when the ZCPR3 CP is going to print its prompt, it realizes that a shell has been defined, but instead of running just one program as a shell, it runs a command sequence. Along with SHSET is CMD, another 1K utility, which prompts the user for a command line and builds the new command line into the command line buffer in place of itself, allowing execution to resume with the command line the user just typed followed by any commands which originally followed CMD. Now commands like the following can be created: SHSET WS;CMD Each time the ZCPR3 CP is going to print a prompt, Word Star is run instead. The users does what he wishes inside of Word Star, and, when he exits, CMD is run. CMD will prompt him for a line: CMD DU:DIR> user input goes here The user's input is entered, it is executed, and then the shell is reinvoked, running Word Star again. To get out of the loop, the handy ZCPR3 Phase 1 command SHCTRL can be run. The command SHCTRL POP will pop the shell stack one level, terminating the WS;CMD sequence, and invoking the next lower shell, whether it is VFILER, VMENU, or the ZCPR3 CP itself. One feature I plan to zip into CMD this evening is sending output to a register to indicate whether an input line was entered. If this is done, ZEX could be run on top of the new SHSET shell: SHSET CMD;IF 9 0;WS;FI would establish the new shell to be: CMD - input a command line from the user and run it in place of CMD in the above script (if the command line was empty, set reg 9 to 0, else set reg 9 to 1) IF 9 0;WS;FI - if reg 9 = 0, run WS (no command was input, so run WS) go back and run CMD again after WS exits or the command line is finished If ZEX was running, ZEX would see the prompt and provide input. The line would be non-empty, so reg 9 = 1, we run the line, and then run CMD again. If ZEX was not running, the user could either input his own line (to be run immediately) or strike return (to enter WS). Of course, in the above example, WS could be anything, such as DBASE II, if the user desired [this capability has no limitation that I can see]. Note that all of this was done without any modification to the ZCPR3 CP (as would have to have been done with ZCPR2). All that was needed were two little 1K COM files. The concept of CMD is still firming up, but this is the idea (altho I may use the ERROR message instead of Reg 9 - have not decided yet). SHSET and CMD are basically running now. Also note that standard ZCPR3 shells, such as VFILER, already allow ZEX to run on top of them and the user can issue any command line he wishes from within the shell (VFILER has a Z command which prompts for command line, stores it, and exits, allowing the command to run and VFILER be reinvoked when the ZCPR3 CP decides to run the shell at the top of the shell stack). Comments? Rick
Chapman.ES@XEROX.ARPA (07/30/84)
Rick As I understood the description, the choice of what to do with the next command depended on the previous command being CORRECT, executed, and the PROGRAM returning a completion code. This is quite different from deciding what to do if the COMMAND LINE itself is in error. In most cases you would want to abort, fix up the command line and restart. Cheryl
RCONN@Simtel20.ARPA (07/31/84)
From: Richard Conn <RCONN@Simtel20.ARPA> Yes, SHSET assumes that the command line is correct. Once ZCPR3 decides to invoke a shell, the shell is processed like any other command line, so your concern would be addressed by an Error Handler should the command line loaded by SHSET be incorrect. Current Error Handlers do not have a provision for aborting a shell, so your point is well-taken. A new error handler, say ERROR5, should be created which can abort a shell as well as redirect execution of the command line (like current error handlers do). Of course, if the SHSET command line includes CMD, then when the conventional error handler is invoked, the user could instruct execution to proceed to CMD, at which point the user could issue a SHCTRL POP command to clear the shell stack. For that matter, a convnetional error handler will simply allow the user to issue the SHCTRL POP command anyway. Hence, your problem is solved by using a conventional error handler. I think I will still add ERROR5, which will be able to deal with the shell stack. Rick