Can a .profile script dynamically set TERM?

[John O'Neill_6]

Hi All,

Yet another question, sorry for asking so
many. This is kind of related to a previous
topic I've raised.

Is it possible to modify the '.profile' script to dynamically assign the TERM environment variable to a value based on the incomming address of a given TELNET.

IE.. if the telnet came from 192.168.0.* use TERM of linux

if the telnet came from 192.168.1.* use
TERM of vt100

Can this be done? All info appreciated.

-John

[curt larson_1 · Accepted solution]

yes it can be done

#find out hostname
host=$(who -R |
awk -F "(" '/pts\/ta/{print $2}'|
awk -F ")" '{print $1}' )

#find ip
ipadd=$(nslookup $host |
awk '/address/ {print $2;}')

case $ipadd in
192.11.22.*([0-9])) TERM=vt100;;
*) TERM=hp;;
esac

[John O'Neill_6]

AWESOME!!

I'll give this a shot later, but that's just what I'm after!

Thanks again, this is a great forum.

-John O'Neill

[John O'Neill_6]

Hi Again...

nslookup is unable to work as the clients
have IP addresses assigned by DHCP.

But.. I modified the script a little
and it's working a treat.

Since their two seperate segments and
two seperate IP networks.. here's what
I did:

#find out hostname
host=$(who -R | awk -F "(" '/pts\/ta/{print $2}'| awk -F ")" '{print $1}' )

#check network
case $host in 192.168.0.*([0-9])) TERM=vt100;;*) TERM=linux;;

This does just what I need, dynamically assigns TERM based on incomming network.

Thankyou very much for your help, I greatly appreciate it!

Regards,

John O'Neill

[Bill Hassell]

Oooohhhh, not a good idea at all!! HP-UX has had an automatic terminal identifier for more than a decade: ttytype and ttytype is normally run in /etc/profile or .profile. Now it's really important to understand what TERM does. It is an environment parameter that points terminal-aware code such as the Curses library to the right set of characteristics for a specific terminal. Curses defines dozens of terminal features in the terminfo database. Unlike other flavors of Unix, there is no termcap (OK, there is a dummy /eetc/termcap but it is ignored by Curses).

Now what about vt100? Well that is but one of a dozen different models of the DEC VT-series of terminals, virtually none of which are actually being used on Unix boxes today. Instead, terminal emulators pretend to be a vt100 or vt220 and emulate features found on those boxes. So here's how to tell if your terminal can be identified:

ttytype -s

You should see soemthing like this:

TERM='70092'; export TERM;
LINES=24; export LINES;
COLUMNS=80; export COLUMNS;
ERASE='^H'; export ERASE;

Now to see what Curses looks at, use untic:

untic 70092
70092|70092a|70092A|70096|hp 7009x/239x series,
am, xhp, da, db, mir,
cols#80, lines#24, lm#0, xmc#0, nlab#8, lh#2, lw#8,
cbt=\Ei, bel=^G, cr=\r, tbc=\E3,
clear=\E&a0y0C\EJ, el=\EK, ed=\EJ$<1>, hpa=\E&a%p1%dC,...

Now checkout linux:

untic linux
untic: no such terminal: linux

So setting TERM=linux guarentees big terminal compatibility issues on HP-UX. Try setting TERM=linux and then run swinstall. So do not hardcode the TERM value as you'll always run into problems. And someday thise users will change their emulator and back come all the problems.

[John O'Neill_6]

Hi,

Thanks for the info, much appreciated.

Here's what the .profile now has:

# Dynamic Terminal Assignment
host=$(who am i -R)

#assign TERM based on network
case $host in
192.168.0.*([0-9])) TERM=linux;;
192.168.1.*([0-9])) TERM=wyse60;;
ourhost) TERM=hp;;
esac

This way, my LINUX users who are all thin clients on the 2nd NIC of the HP UX box get allocated a TERM of linux.

Now, HP UX has no idea what a 'linux' Terminal is, however.. the PROGRESS 4gl does as it has its own termcap capabilities.

For legacy reasons, our other users are still on Wyse60 (Because, our counter based terminals are still Wyse 60)

And anyone else gets a basic HP terminal (Console etc).

Also, EVERYONE logs into the host with the same user id, that's company policy. The application has its own password/user security features.

This has been tested and it works fine.

I'll stick with this unless setting TERM to 'linux' and running SWINSTAL is guaranteed to provide me with proper Linux Terminal support.

I'm suprised that HP UX 11i doesn't know about the LINUX terminal type, as I think this issue will come up more often, not everyone uses GUI clients (esp in banking).

Will running SWINSTAL with a value of 'linux' as the TERM give us LINUX terminal settings in HP UX 11i?

Thanks :)

-John

[Bill Hassell]

No, swinstall will discover that there is no such terminal as linux (and truthfully, there is no 'terminal' called linux since linux is an operating system). Some linux distros may have a terminal emulator but unike Wyse, HP, ANSI, VT(DEC), etc, there is no industry standard for 'linux' as a defined terminal product or emulator.

Keep in mind that SAM and swinstall look for $DISPLAY first, and if found, will attempt to start an X11 window on the host defined in $DISPLAY. X11 doesn't use TERM at all. But if $DISPLAY is not set then SAM and swinstall will startup in character mode and both will immediately fail because TERM=linux is meaningless. The two apps will ask you to supply a valid terminal ID or4 terminate.

Now you can certainly create a linux terminal using untic and tic plus a complete read of the terminfo man page. Oh, you'll also need a complete tech refernce for the program used on the linux side as a terminal emulator so you can match up characteristics.

[John O'Neill_6]

Thanks Bill..

Good luck with your new endeavours too :)

I really appreciate the extremely high
quality feedback on this forum.

I discovred that there is some kind of
handshaking going on with TELNET (Doing
some reading atm) clients.

The host seem to ask 'How are you?'
The client responds with a 'I'm a
'

PC's telnetting in get a TERM of wyse60.
The linux clients get a TERM of linux.

I found this out by having the FIRST
thing the .profile script do was echo
$TERM.

So, my only problem is the poor old glass
terminals.. they get a term of '60'.

So.. I put an 'IF' clause into our
application users .profile script that
weeds out the '60' and puts in a 'wyse60'
then everything works.. all three user
types can log in an run our app with the
one user ID as the PROGRESS 4gl is able
to deal with the LINUX terminal type
with its own termcap settings.

Probably not the most elegant way of
sorting things out, but i'm getting rid of
these old Wyse 60 things soon anyway.

Thanks heaps for your help, much appreciated! :)

-John

[Bill Hassell]

What you are seeing is the telnet protocol using subcode 31 for terminal type and window sizes. I was baffled several years ago when I discovered TERM (and COLUMNS and LINES) had been set before the start of /etc/profile. This is a great feature ONLY when every box is the same (ie, all linux). But the problem is that a PC (or linux or any other opsystem) if it sets TERM for telnet subcodes, will use something that is only meaningful to the local system. The problem is that you aren't running the app on the local system, you are running on another system and that system needs to know how to handle your terminal.

So you want to remove the code in /etc/profile that tests for TERM being already set (HP wrote the profile code assuming every box would be 100% HP-UX). That is the job for ttytype...it will take care of the glass terminals as well as any reasonable emulator. BTW: 60 is a valid TERM value for HP-UX (hint: untic 60)

[John O'Neill_6]

Hi,

Sorry, tried that... doesn't work for these rotten old terminals, hence my quest to dynamically assign TERM based on the source of the incomming connection...

Once the old glass terminals get sent to the big compacter :) I'll remove the code in the .profile, as by then it will indeed be redundant (as you said it will) ;-).

Effectively, the problem changed from 'how do I dynamically set the terminal for all users?' to 'how can I have dynamic allocation AND support these old terminals?'.

These old terminals are truly awful, disgusting things, they don't properly emulate anything except Wyse60 and even that is painful and require use of the 'stty' command to get working.


:)

[Bill Hassell]

I understand about old terminals. There are dumb terminals and there are comatose boxes (and emulators for that matter). The Wyse60 did have answerback capability which is how ttytype determines the various terminal types. However, you can still automate the process by using ttytype -as which will automatically set TERM=unknown for comatose terminals. You can then do something like this:

[[ $TERM = "unknown" ]] && TERM=wyse60

Another usefull option for ttytype in discovering terminal types is -v as in:

ttytype -sv
ttytype: ANSI terminal response "^[[?62;1;2;6;7;8;9c" mapped to "vt200"
ttytype: COLUMNS=80; LINES=24
TERM='vt200'; export TERM;
LINES=24; export LINES;
COLUMNS=80; export COLUMNS;
ERASE='^?'; export ERASE;