[Info-vax] disabling a CTRL/Y ast

[VAXman- at SendSpamHere.ORG]

In article <c101902e-0a54-412a-8d8b-b49ad7e0d9e8 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
>On Friday, January 8, 2016 at 9:11:47 AM UTC-5, Tom Adams wrote:
>> On Thursday, January 7, 2016 at 11:21:27 AM UTC-5, VAXman- wrote:
>> > In article <3a583568-e33e-446e-9805-6ea94f9ebf71 at googlegroups.com>, Tom Adams <tadamsmar at gmail.com> writes:
>> > >On Wednesday, January 6, 2016 at 12:22:06 PM UTC-5, Stephen Hoffman wrote:
>> > >> On 2016-01-06 16:46:32 +0000, Tom Adams said:
>> > >> 
>> > >> > I want to turn ctrl/y into a noop in certain regions of code and turn 
>> > >> > ctrl/y into an exit in other regions of code.
>> > >> 
>> > >> Some background: I've posted more than a few replies here in the 
>> > >> comp.os.vms newsgroup, specifically discussing the particular 
>> > >> application in question and its general design, and an unfortunate 
>> > >> aggregation of the UI and the more critical code paths, and your 
>> > >> understandable preference to avoid restructuring the application code 
>> > >> through reworking the existing design to block ^Y from arriving within 
>> > >> the most critical sections of the code.
>> > >> 
>> > >> > I do find that it is necessary to run lib$disable_ctrl at the beginning 
>> > >> > of the program and lib$enable_ctrl at the end of the program to restore 
>> > >> > the previous CLI state, but I need to run asts to do the rest.
>> > >> 
>> > >> If you want ASTs in some parts of the code and not in others, then 
>> > >> you're going to have to wrap those sections appropriately.   That's if 
>> > >> you don't decide to migrate those critical code sections into another 
>> > >> process context, or related steps.  Because beyond the potential for ^Y 
>> > >> in these sections and the associated issues you're having with the 
>> > >> image rundown processing in the absence of an EXIT command, other sorts 
>> > >> of generic application failures ("bugs") or any arriving $forcex calls 
>> > >> or such activities can potentially still leave the application in an 
>> > >> indeterminate state.
>> > >> 
>> > >> 
>> > >> 
>> > >> -- 
>> > >> Pure Personal Opinion | HoffmanLabs LLC
>> > >
>> > >Here's an example of what I am trying to do that seems to work OK.
>> > >I guess a forced exit from a bug could leave the CTRL\Y in
>> > >the disabled state at the CLI instead of the original state.
>> > >
>> > >Also, it's possible that someone could define TT to be some terminal
>> > >other than the login terminal.  VMS leaves all the built-in process
>> > >logicals that refer to the login terminal vulnerable to redefinition.
>> > >It may be possible to roll your own safe (executive, no_alias) logical
>> > >name via a call in syslogin.
>> > >
>> > >Also, I still need to cover the cases where this code runs in a context
>> > >where TT is not defined.
>> > 
>> > 	PROGRAM MY_TERMINAL
>> > 	IMPLICIT NONE
>> > 
>> > 	INCLUDE '($DSCDEF)'
>> > 	INCLUDE '($JPIDEF)'
>> > 	INCLUDE '(LIB$ROUTINES)'
>> > 
>> > 	INTEGER*4 STATUS
>> > 
>> > 	RECORD	/DSCDEF1/ TERMINAL
>> > 
>> > 	TERMINAL.DSC$W_MAXSTRLEN = 0
>> > 	TERMINAL.DSC$B_DTYPE = DSC$K_DTYPE_T
>> > 	TERMINAL.DSC$B_CLASS = DSC$K_CLASS_D
>> > 	TERMINAL.DSC$A_POINTER = 0
>> > 
>> > 	STATUS = LIB$GETJPI(JPI$_TERMINAL,,,,TERMINAL,)
>> > 	IF (STATUS.AND.1) THEN
>> > 	  STATUS = LIB$PUT_OUTPUT(TERMINAL)
>> > 	ENDIF
>> > 
>> > 	CALL SYS$EXIT(%VAL(STATUS))
>> > 	END
>> > 
>> > -- 
>> > VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
>> > 
>> > I speak to machines with the voice of humanity.
>> 
>> There is an issue.
>> 
>> MY TERMINAL returns a blank string when you spawn it off the CLI:
>> 
>> SPAWN RUN MY_TERMINAL
>> 
>> But (oddly enough) the TT logical name is defined in that spawned interactive process.  The process has TT, SYS$COMMAND and all that but no login terminal returned by GETJPI. And, it 
>> 
>> This user interface program I am trying to improve gets used in all sort of processes: interactive processes, spawned interactive processes, batch jobs, detached processes, processes spawned by detached processes.
>> 
>> I think the best thing to do is for the program use the special processing for CTRL/Y in all interactive processes.
>> 
>> But, I cannot use the login terminal from GETJPI in a spawned interactive process.
>> 
>> I can think of some options:
>> 
>> 1. use TT
>> 2. use TT with a "_" added to the front
>
>I mean translate TT and add a "_" on the front, but now I am thinking I might
>as well use TT.
>
>> 3. do not provide the special processing in detached interactive processes. Maybe just disable CTRL/Y in that case.
>> 
>> BTW, when you hit CTRL/Y in an image in the spawned interactive process, it kills the process, it does not suspend the image. It acts differently from a normal interactive process.
>> 
>> Is there some way to tell if you are in a spawned interactive process other than checking with GETJPI for the lack of a login terminal name?
>

IF $GETJPI(JPI$_PID) .NE. $GETJPI(JPI$_MASTER_PID) THEN SPAWNED

If you take the code from my last post, you should be able to use it and a
call to LIB$GETJPI(JPI$_PID,,,CURRENT_PID,,) with CURRENT_PID define as an
INTEGER*4 and compare it with MASTER_PID.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.