dhesi@bsu-cs.UUCP (Rahul Dhesi) (05/22/87)
In article <1135@byzantium.swatsun.UUCP> schwartz@swatsun (Scott Schwartz) writes: >In article <667@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: [..trying to explain why VMS has no control structures and concluding:] >> ...The command >> interpreter >> can't save information and reuse it very easily... > [...] >But: I do know that if you hit the <up arrow> key the shell gives you >the previous command line. Repeat n-times and you get the nth previous >command line. If it can do this, I can't believe it couldn't support >multiple commands on one line. I don't think the command interpreter remembers past command lines. I think it just does a LIB$GET_COMMAND call to a library routine, and the previous command lines are remembered in the device driver for the controlling device or in the kernel somewhere. (The 20-command limit suggests that space to store commands is tight, so it could be in the device driver.) I believe that when an applications program does a LIB$GET_COMMAND the user can recall previous input lines too. [Disclaimer: I could be wrong.] >Speaking of fun command interpreters, Primos supports a command >language that penalizes you for hitting <break> too many times (the >exact number of times is set by your system administrator, I think). >Also, you can construct an infinite recursive loop in the command >processor that eventually terminates with >"FATAL$ USER ENVIRONMENT REINITIALIZED" I saw that happen back in the Dark Ages when I was forced to use Primos. I hit the break key a lot back then, because once in a while I would ask for a file to be typed to the screen, and then decide I had seen enough. (This happens a lot when you are diallling up at 300 bps.) Primos did not support the flushing of output with the equivalent of control O so the break key was your only option. (I hope things have improved since then.) My guess is that when you hit break at Primos, a signal handler takes over, with the previous context saved on a stack. The signal handler becomes the new command interpreter, and when you hit break again, you get a new recursive level. When the stack is about to overflow, you get an error message, and several levels of context are popped from the stack and get lost. I never did figure out how to restore a previous command level, though; maybe this was just a hook for future implementation of multiple command levels and they never got around to finishing it. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
eal@tut.UUCP (Lehtim{ki Erkki) (05/24/87)
In article <685@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I believe that when an applications program does a >LIB$GET_COMMAND the user can recall previous input lines too. >[Disclaimer: I could be wrong.] > Yes, they can, but only the latest one, not 20. There are some system programs, such as DEBUG and MAIL, who can also recall all 20 commands. -- Erkki A. Lehtim{ki eal@tut.uucp