EVERHART%ARISIA@rca.com.UUCP (02/23/87)
H. Steinberg (?) writes of a nifty feature wherein one can gain a new prompt and do things under Unix on receipt of a ^Z type-in. I've seen this done under VMS by typing ^Y and then various SPAWN/NOWAIT commands and continue commands. The SET PROMPT command in these cases is essential to keep track of which process you're talking to and you need to remember that all processes see the ^C and ^y signals you type (so you have to continue them all). But it's a way of getting an interactive prompt to do something useful when a process you started turns out to take longer than is convenient. Perhaps someone else who does more of this can give more detail. Glenn Everhart Everhart%Arisia@RCA.com
McGuire_Ed@GRINNELL.MAILNET.UUCP (03/04/87)
>H. Steinberg (?) writes of a nifty feature wherein one can gain a new >prompt and do things under Unix on receipt of a ^Z type-in. > I've seen this done under VMS by typing ^Y and then >various SPAWN/NOWAIT commands and continue commands. [. . .] > Glenn Everhart >Everhart%Arisia@RCA.com It sounded if the UNIX feature the person was asking for wasn't an interrupt. Suppose I'm running something that will take awhile to complete. I want to create a subprocess, but I want the parent process to continue working. I don't know how to do that, but I'd love to find out if it's possible! Ed McGuire Grinnell College MCGUIRE@GRIN2.BITNET
carl@CITHEX.CALTECH.EDU.UUCP (03/04/87)
>> H. Steinberg (?) writes of a nifty feature wherein one can gain a new >> prompt and do things under Unix on receipt of a ^Z type-in. >> I've seen this done under VMS by typing ^Y and then >> various SPAWN/NOWAIT commands and continue commands. [. . .] >> Glenn Everhart >> Everhart%Arisia@RCA.com > > It sounded if the UNIX feature the person was asking for wasn't an > interrupt. Suppose I'm running something that will take awhile to > complete. I want to create a subprocess, but I want the parent process to > continue working. I don't know how to do that, but I'd love to find out > if it's possible! It's done as follows: 1) If you've got NOCONTROL_Y set, you're out of luck; it can't be done. 2) Hit a control-Y (not a control-C, since the image may be trapping for control-C's, in which case, you won't get what you want. 3) Type the command "SPAWN/NOWAIT" with any other appropriate qualifiers you might want: e.g., it's easier to keep track of what's going on if you use a distinct prompt for the subprocess, if you have SYS$COMMAND or SYS$OUTPUT directed away from the terminal, you'll want to explicitly direct them back for the subprocess, and so on. 4) Once the subprocess is spawned, issue the CONTINUE command to the original process. You've now accomplished what was described above. In some ways, this is superior to the UNIX version; in others, it's decidedly worse. If you log out of the subprocess, you automatically find yourself talking to the previously "background" process again. On the other hand, if the original process decides it wants terminal input, the only warning you'll have is that it will issue its own prompt (which is why I suggest a different prompt for the subprocess. There is one big gotcha here though. It's illustrated by the following procedure: $ IF P1 .NES. "" THEN GOTO NEXT $ SET CONTROL=(T,Y) $ SPAWN/NOWAIT/INPUT='F$TRN("SYS$COMMAND") - $ @'F$ENV("PROCEDURE")' X $ LOOP: WRITE SYS$OUTPUT F$TIME, " F$ENVIRONMENT(""CONTROL"") = ",- $ F$ENVIRONMENT("CONTROL") $ WAIT 00:01:00.00 $ GOTO LOOP $ NEXT: SPAWN/INPUT='F$TRN("SYS$COMMAND")' - $ ATTACH/ID='F$GETJPI("","PID")' $ WRITE SYS$OUTPUT "STOPPING JOB" $ STOP /ID=0 What this does is as follows: You invoke the procedure without any arguments; The procedure spawns an ASYNCHRONOUS subprocess which reinvokes the procedure with an argument. Meanwhile, the original process starts, at one-minute intervals, whether control-t and control-y are enabled or disabled. The subprocess now spawns a SYNCHRONOUS subprocess which immediately reattaches to the first subprocess, which then commits suicide, killing the second subprocess at the same time, of course. Now here's the fun part: Though the procedure explicitly enabled both control-t and control-y, and though it's still reporting them as being enabled, you'll have to go elsewhere to stop execution of this procedure: You see, the second subprocess was given access to the interrupts when it was created as a synchronous subprocess; when it attached to the first subprocess, it passed access to the signals to it. The first one, however, being asynchronous, felt no onbligation to inform its parent process when it killed itself, and the second subprocess didn't even know about the original process. Thus, the process you're left with is ignoring the interrupts, assuming they will be serviced by one of its (no longer extant) subprocesses, and will continue to do so until it receives an appropriate termination message in a temporary mailbox. Of course, there's no subprocess to send it a termination message anyjore, so you either have to make a good guess and manually copy the appropriate messaage to the mailbox, or else log in elsewhere and delete the stalled process. Have fun.
McGuire_Ed@GRINNELL.MAILNET.UUCP (03/20/87)
>> H. Steinberg (?) writes of a nifty feature wherein one can gain a new >> prompt and do things under Unix on receipt of a ^Z type-in. >> I've seen this done under VMS by typing ^Y and then >> various SPAWN/NOWAIT commands and continue commands. [. . .] >> Glenn Everhart >> Everhart%Arisia@RCA.com > > It sounded if the UNIX feature the person was asking for wasn't an > interrupt. Suppose I'm running something that will take awhile to > complete. I want to create a subprocess, but I want the parent process to > continue working. I don't know how to do that, but I'd love to find out > if it's possible! It's done as follows: 1) If you've got NOCONTROL_Y set, you're out of luck; it can't be done. 2) Hit a control-Y (not a control-C, since the image may be trapping for control-C's, in which case, you won't get what you want. 3) Type the command "SPAWN/NOWAIT" with any other appropriate qualifiers you might want: e.g., it's easier to keep track of what's going on if you use a distinct prompt for the subprocess, if you have SYS$COMMAND or SYS$OUTPUT directed away from the terminal, you'll want to explicitly direct them back for the subprocess, and so on. 4) Once the subprocess is spawned, issue the CONTINUE command to the original process. You've now accomplished what was described above. In some ways, this is superior to the UNIX version; in others, it's decidedly worse. If you log out of the subprocess, you automatically find yourself talking to the previously "background" process again. On the other hand, if the original process decides it wants terminal input, the only warning you'll have is that it will issue its own prompt (which is why I suggest a different prompt for the subprocess. There is one big gotcha here though. It's illustrated by the following procedure: $ IF P1 .NES. "" THEN GOTO NEXT $ SET CONTROL=(T,Y) $ SPAWN/NOWAIT/INPUT='F$TRN("SYS$COMMAND") - $ @'F$ENV("PROCEDURE")' X $ LOOP: WRITE SYS$OUTPUT F$TIME, " F$ENVIRONMENT(""CONTROL"") = ",- $ F$ENVIRONMENT("CONTROL") $ WAIT 00:01:00.00 $ GOTO LOOP $ NEXT: SPAWN/INPUT='F$TRN("SYS$COMMAND")' - $ ATTACH/ID='F$GETJPI("","PID")' $ WRITE SYS$OUTPUT "STOPPING JOB" $ STOP /ID=0 What this does is as follows: You invoke the procedure without any arguments; The procedure spawns an ASYNCHRONOUS subprocess which reinvokes the procedure with an argument. Meanwhile, the original process starts, at one-minute intervals, whether control-t and control-y are enabled or disabled. The subprocess now spawns a SYNCHRONOUS subprocess which immediately reattaches to the first subprocess, which then commits suicide, killing the second subprocess at the same time, of course. Now here's the fun part: Though the procedure explicitly enabled both control-t and control-y, and though it's still reporting them as being enabled, you'll have to go elsewhere to stop execution of this procedure: You see, the second subprocess was given access to the interrupts when it was created as a synchronous subprocess; when it attached to the first subprocess, it passed access to the signals to it. The first one, however, being asynchronous, felt no onbligation to inform its parent process when it killed itself, and the second subprocess didn't even know about the original process. Thus, the process you're left with is ignoring the interrupts, assuming they will be serviced by one of its (no longer extant) subprocesses, and will continue to do so until it receives an appropriate termination message in a temporary mailbox. Of course, there's no subprocess to send it a termination message anyjore, so you either have to make a good guess and manually copy the appropriate messaage to the mailbox, or else log in elsewhere and delete the stalled process. Have fun.