Cobol - TERM settings on UNIX (Another off the wall question)

Author

TERM settings on UNIX (Another off the wall question)

Chris

2006-06-30, 6:55 pm

PLATFORM: HP-UX 11i
COMPILER: MF SE 4.0 SP 2

I know that "cobtermmode" can be call to switch between standard and
wide mode terminal definitions (i.e., vt100 & vt100-w), but what if I
want to completely alter the terminal type?

We have software (Double Vision) that allows us to take control of a
users session - however, if the target user is running a different
emulation than we are, the displays get all garbled (as one would
expect).

I'd like to be able to have the application set the TERM value based on
some command or function key so that when we take over these sessions
(and, for that matter, return control to the users) we can adjust the
TERM setting accordingly.

Any ideas?

I know I can overide the TERM value in the environment, but then how
would I force a "reset" (tput reset) so that things adjust
appropriately all around?

Thanks in advance!

Chris

Richard

2006-06-30, 6:55 pm

Chris wrote:
> PLATFORM: HP-UX 11i

> I'd like to be able to have the application set the TERM value based on
> some command or function key so that when we take over these sessions
> (and, for that matter, return control to the users) we can adjust the
> TERM setting accordingly.

Surely the TERM variable is set by the login. It should be detecting
the terminal type and setting it appropriately by getting a response
from the terminal or emulator. If the emulator is not sending the
correct response string then get the user to set it correctly in the
terminal software.

Alternately set the TERM with a shell script before the cobol
application starts.

Chris

2006-07-05, 6:55 pm

Richard wrote:
> Chris wrote:
>
>
> Surely the TERM variable is set by the login. It should be detecting
> the terminal type and setting it appropriately by getting a response
> from the terminal or emulator. If the emulator is not sending the
> correct response string then get the user to set it correctly in the
> terminal software.
>
> Alternately set the TERM with a shell script before the cobol
> application starts.

Thanks Richard.

I understand the basics of TERM and how to use it, but I am faced with
the unique situation where I actually want to "force" a partciular
emulation for a given application. And when the user exits the
application, I'd like to put the TERM back to its original value.

Chris

Richard

2006-07-05, 6:55 pm

Chris wrote:

> I understand the basics of TERM and how to use it, but I am faced with
> the unique situation where I actually want to "force" a partciular
> emulation for a given application. And when the user exits the
> application, I'd like to put the TERM back to its original value.

Your best approach is to force the users to have the correct terminal
emulation before they take over the session. Anything that changes
what the run-time is using for setting will require the program to
activate this internally. That is, every ACCEPT that could be active
when the program was taken over, and every perform loop it might be in,
would have to check for some signal that a terminal type reset was
required so that it can call the required routine to do so. It cannot
be done from an external process.

Then you have the problem that the signal from the terminal cannot be a
simple function key because these may be different for each terminal
type. That is the program may be expecting a F12 as the signal but the
F12 key on the terminal taking over may not be sending the correct
sequence for the program to notice that it is the F12.

Also MF uses curses (AFAIK) and this only reads the TERM on initscr()
so you would need to CANCEL the ADIS module and restart it - you
weren't expecting the current screen contents to automatically
redisplay were you ?

Chris

2006-07-06, 7:55 am

All understood.

No - I'm not looking for it to redraw. After the TERM swap, I will be
initializing and painting/accepting screens as necessary, then blank
the screen and switch back to the old TERM type.

I thought I'd be clever and try something like this, with WS-NORMAL set
to a pic x comp-x value 0.

DISPLAY "TERM" UPON ENVIRONMENT-NAME.
DISPLAY "new-value" UPON ENVIRONMENT-VALUE.

CALL "cobtermmode" USING WS-NORMAL END-CALL

But even this trick did not work for me.

I'm still thinking about it - but I think I may end up forcing them
emulation to be correct going into the session.

Richard wrote:
> Chris wrote:
>
>
> Your best approach is to force the users to have the correct terminal
> emulation before they take over the session. Anything that changes
> what the run-time is using for setting will require the program to
> activate this internally. That is, every ACCEPT that could be active
> when the program was taken over, and every perform loop it might be in,
> would have to check for some signal that a terminal type reset was
> required so that it can call the required routine to do so. It cannot
> be done from an external process.
>
> Then you have the problem that the signal from the terminal cannot be a
> simple function key because these may be different for each terminal
> type. That is the program may be expecting a F12 as the signal but the
> F12 key on the terminal taking over may not be sending the correct
> sequence for the program to notice that it is the F12.
>
> Also MF uses curses (AFAIK) and this only reads the TERM on initscr()
> so you would need to CANCEL the ADIS module and restart it - you
> weren't expecting the current screen contents to automatically
> redisplay were you ?

Michael Wojcik

2006-07-06, 6:55 pm

In article <1152131041.625092.247460@j8g2000cwa.googlegroups.com>, "Richard" <riplin@Azonic.co.nz> writes:
>
> Chris wrote:
>

Really the only way to do this would be to use a pty (pseudo tty),
and emulate the terminal type the application thinks it's using,
converting to the actual terminal type.

That provides the "extra layer of indirection" which solves all
problems. It's how utilities like GNU screen work.

Unfortunately, terminal emulation is cumbersome and tricky, and ptys
aren't exactly trivial (and were only standardized in 2004, so many
non-standard implementations still exist).

If you have control of the application's environment when it starts,
it's a bit easier, because you can force TERM to some known value.
Then you only have to emulate that one terminal type, and convert
the application's control codes for that type to the corresponding
ones for the terminal it's actually running in.

I did this for some testware years ago: I had a full-screen curses
application that I wanted to write automated tests for, so I created
a terminfo entry for a new terminal type where all the control codes
were actually plain-text markup: "[B]" for start-bold and so forth.
(My app never generated any of these strings as part of its normal
output, so I didn't need an escape character.) Then I'd run the app
with TERM set to my terminal-type name, and its output could easily
be parsed with an awk script. Similarly, my terminal definition
defined the PF keys as "[F1]", "[F2]", and so forth, so I could just
write those strings to it as part of my test scripts.

If you don't control the application's startup environment, it's a
bit tougher, because when you take over the app you have to figure
out what terminal type it thinks it's talking to, then load that
terminal's termcap/terminfo data so you can set up your emulator.
Somewhat more work, and you have to be prepared to deal with odd
terminals that lack certain capabilities.
[color=darkred]
> Also MF uses curses (AFAIK) and this only reads the TERM on initscr()
> so you would need to CANCEL the ADIS module and restart it - you
> weren't expecting the current screen contents to automatically
> redisplay were you ?

We actually use our own terminal-control library which is similar to
curses (probably to work around vagaries in pre-POSIX curses
implementations), but the same issue applies. Pretty much all Unix
applications that do terminal-specific I/O - whether directly, or
using termcap/terminfo directly (eg vi), or through curses or a
similar higher-level interface - only check the value of TERM once.

You *can* get many apps to redraw the screen by sending SIGWINCH
(the "window change" signal) on some Unix flavors, but SIGWINCH isn't
in SUSv3 and applications aren't required to support it even on
platforms that do have it.

--
Michael Wojcik michael.wojcik@microfocus.com

Be sure to push the button of the bottom, and push the button of the
settlement page indicated next only once, there is fear of the bottom
rhinoceros multiplex lesson money. -- Sukebe Net

Sponsored Links