Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!hplabs!sri-unix!RCONN@Simtel20.ARPA From: RCONN@Simtel20.ARPA Newsgroups: net.micro.cpm Subject: SHSET Message-ID: <567@sri-arpa.UUCP> Date: Tue, 31-Jul-84 08:14:00 EDT Article-I.D.: sri-arpa.567 Posted: Tue Jul 31 08:14:00 1984 Date-Received: Sat, 4-Aug-84 00:58:58 EDT Lines: 21 From: Richard ConnYes, 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