bussiere@ganymede.DMI.USherb.CA (Luc Bussieres) (02/20/91)
I wan't to know if there is a way that at login Unix could know which type of terminal is hooked to a line. Here we have multiple type of terminal that may hook to any port. We are running sunos 4.1.1 on sun3 and sun4. The problem is that we have vt100 and vt220 terminal. The vt220 support international characters while the vt100 doesn't. Because we are a french university, we need these characters. If I define every port as vt220 in the ttytab file, the term is set to vt220 for each user even if they are on a vt100. If I define every port to vt100, the people with vt220 can't use the international characters without having to first do those three lines: setenv TERM vt220 source .login stty pass8 Is there a solution (that will be transparent to the users if possible) to find the type of the terminal during the login procedure? -- Luc Bussieres ---- Analyste - Dep. de Mathematiques et Informatique Universite de Sherbrooke Internet : bussiere@dmi.usherb.ca Tel: (819) 821-7981
mike@bria (02/21/91)
In an article, ganymede.DMI.USherb.CA!bussiere (Luc Bussieres) writes: | | I wan't to know if there is a way that at login Unix could know |which type of terminal is hooked to a line. Here we have multiple type |of terminal that may hook to any port. We are running sunos 4.1.1 on |sun3 and sun4. I kind of like the ``tset'' tool myself. Cheers, -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
elliss@eecae.uucp (Stew Ellis) (02/21/91)
In article <476@bria>: >In an article, ganymede.DMI.USherb.CA!bussiere (Luc Bussieres) writes: >| >| I wan't to know if there is a way that at login Unix could know >|which type of terminal is hooked to a line. Here we have multiple type >|of terminal that may hook to any port. We are running sunos 4.1.1 on >|sun3 and sun4. >I kind of like the ``tset'' tool myself. The problem with this is that he wants it to be transparent to the users. I use tset myself because one of my terminals does not respond to an enquiry from the host. All DEC type terminals respond to an ansi code that asks what terminal you have with a unique code for each type of DEC terminal. The terminal manuals should tell you what the codes are, then you can write a trivial shell script to send them and interpret the returned codes. >Cheers, >-- >Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. >Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike >------------------------------------------------------------------------------- >Remember folks: If you can't flame MS-DOS, then what _can_ you flame? R. Stewart (Stew) Ellis Department of Humanities and Social Science GMI Engineering & Management Institute Flint, MI elliss@frith.egr.msu.edu
dag@persoft.com (Daniel A. Glasser) (02/22/91)
Assuming that you are always (or at least, usually) talking to DEC
(or compatible) terminals or emulators thereof, there's a simple way
to do this. Write a program that sends the DA (Device Attributes) control
sequence, "<ESC>[c". The terminal will respond with a report which identifies
the terminal family and gives a list of what it can do.
The VT100 responds with "<ESC>[?<n;m>c" where <n;m> is a decimal string
with value < 60, usually followed by a semicolon and another decimal string
which identifies a bit more about the terminal.
VT100 w/printer: <ESC>[?1;2c
VT101 <ESC>[?1;0c
VT102 <ESC>[?6c
and so on. If what you are interested in is VT100 level vs. VT200+ level,
you should just pay attention to the first decimal parameter after the
question mark. VT200 level terminals will respond with a sequence
where the first decimal parameter is >= 60. A VT220 or VT240 will have 62
here, a VT3[234]0 will have 63, a VT420 has 64. On these terminals, the
decimal values that follow the first semicolon list some of the features
of the terminal sending the report.
The features listed for DEC VT[234]xx terminals include:
1 132 column support (EVO on VT100, I think)
2 Printer port installed
3 ReGIS display
4 SIXEL graphics I/O
6 Selective Erase (DECSEL/DECSED/DECSCA support)
7 Downloadable Character Set (DRCS)
8 User Defined Keys (UDK)
9 National Replacement Character sets (NRCs)
15 DEC Technical Character Set
18 Windowing (split screen) capability
19 Dual Sessions
21 Horizontal Scrolling
(I got these from looking in the VT240 and VT420 manuals, there are
many others, including locator device support, etc.)
Your program should send the DA request, and then wait for a response
for a very short time (maybe based on baud rate). If no response is
received, send the string "<ESC>\" to the terminal just in case it is
a REAL VT52, which would be put in no-scroll mode by the "<ESC>[" of the
DA request. (You may also want to then send the string "<ESC>Z" and see
if you get "<ESC>\z" back, since that's the VT52 response to the DECID
sequence.)
Based on what (if anything) your program got, you should write (to stdout)
the terminal type desired. This then gets used in a .login or .profile
script as
(.login) setenv TERM
(.profile) TERM=`/usr/local/bin/dectermtype` ; export TERM
I will leave the writing of this program as an exercise for the reader.
Note that you should NOT simply match the string the terminal sends
against a table of predefined strings, since various flavours of various
DEC terminal family terminals (and emulators thereof) report different
features. Also, make sure you read the entire report (up to and including
the 'c' at the end) if you see any of it, otherwise the remainder of the
report might end up causing future problems. Also, read this with echo
turned off for best results.
I hope this helps.
--
Daniel A. Glasser | Persoft, Inc. | dag@persoft.com
"Their brains were small, and they died."arnej@Lise.Unit.NO (Arne Henrik Juul) (02/24/91)
At our site we use the tset program. This is not as transparent to users as it might have been, but it works better with all those strange terminal types and different machines and the telnet-ing around that we do all the time. This means that at most initial logins, tset asks the users which terminal he has (probably you would want to use vt100 as the default) like this: TERM = ( vt100 ) and you may answer with just return or with 'vt200' if that is better, or even with 'dumb' if it's some braindamaged old terminal... When you telnet or rlogin later on, things will normally be quite OK without extra input. Relevant things from our /local/skel/all.login: if ( ! $?TERM ) setenv TERM '?unknown' if ( "$TERM" == network \ || "$TERM" == dumb \ || "$TERM" == unknown \ || "$TERM" == su ) then setenv TERM '?unknown' endif set noglob set ttynam=`tty` switch ( `tty` ) case /dev/console: case /dev/tty[pqr]*: eval `tset -s -r -Q $TERM` breaksw default: eval `tset -s -r -Q ?$TERM` endsw unset noglob Regards, Arne H. Juul, system administrator solan.unit.no arnej@lise.unit.no -- internet mail please -- hacker - Arne.Juul@unit.no -- X/400 mail for sadists -- I - juul@norunit.bitnet -- bitnet mail if you have to. -- hope -
cosgrok@jacobs.CS.ORST.EDU (Kevin Cosgrove) (02/24/91)
Setting the terminal type at login with something like "TERM=(vt100)" is pretty good, until the user moves to a new terminal and absent mindedly hits return before realizing they're on an old ADM terminal. For that reason I have the following in the skeleton .cshrc file for users. alias newterm 'set noglob;eval `tset -srQ ??`;unset noglob' -- Kevin Cosgrove <cosgrok@jacobs.CS.ORST.EDU>
ooms@delgeo.nl (Frank Ooms) (02/26/91)
We use qterm. It was posted to comp.sources.unix in 1987 (volume 8). It uses a little database of responses for some terminals, of course you can add the response of your own terminal to that list. More than one query string can be sent, until a response is found that is matched. Actually it works quit well. The way it is invoked is byt adding these line to /etc/login: set term = `qterm -q -u vt100n` set noglob eval `usr/ucb/tset -s -Q $term` success, -- /* Frank Ooms, +31 15-621554 * * ooms@delgeo.nl * * ..!mcsun!hp4nl!delgeo!ooms */
bob@wyse.wyse.com (Bob McGowen x4312 dept208) (03/01/91)
In article <1991Feb23.173043.3526@ugle.unit.no> arnej@solan1.solan.unit.no writes: >At our site we use the tset program. This is not as >transparent to users as it might have been, but it works ^^^^^^^^^^^ Why? If set up corrctly it can be, I think. ---deleted discussion of default terminal type and Cshell script ---for checking various terminal types. Why not let tset do it? It has a -m option to map terminal types based on a database in /etc, which under XENIX and SysV/386 is called _ttytype_. I use the following line to check for defined types (XENIX system). In the case where the type is unkown or dialup or switch (or any other generic name), you can ask the user for input or select for that user a particular terminal type: eval `tset -m ansi:ansi -m switch:wy60 -m dialup:\?vt100 \ -m :\?vt100 -s -Q` In /etc/ttytype the following lines exist: ansi console ansi tty01 ... ... ansi tty12 unknown tty1a dialup tty1A ... ... switch tty5a switch tty5b ... ... If I log in on the console or virtual tty's, I will get type ansi; logging in over the data switch will give me wy60, no questions; dialing in via modem I usually use Procomm in vt100 emulation but could be using cu from some other UNIX system, so tset asks me if vt100 is ok, CR accepts or type in what I want; if there is nothing to match in any preceding -m, use the last one to ask if I am using a vt100. An advantage of tset on a XENIX (BSD too??) system is that it will set the env. variable TERMCAP equal to the termcap entry for the terminal defined. Any program that wants to can now get this from the environment without re-reading a termcap file. tset does not do this under SysV/386, it only sets TERM. The -s option is required for this to work. tset generates output to set and export the variables (it will make setenv commands if you use the csh). The -Q option makes it totally quiet, no output is done unless the \? map option is hit. >Regards, Arne H. Juul, system administrator solan.unit.no > >arnej@lise.unit.no -- internet mail please -- hacker - >Arne.Juul@unit.no -- X/400 mail for sadists -- I - >juul@norunit.bitnet -- bitnet mail if you have to. -- hope - Bob McGowan (standard disclaimer, these are my own ...) Product Support, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com