jim@tiamat.fsc.com (Jim O'Connor) (01/13/91)
I have recently discovered that when doing an "rlogin" from hostA to hostB (where hostA is any TCP/IP machine, and hostB is an SCO Xenix machine, running TCP/IP 1.0.1h), that hostB does not correctly set TERM to whatever value it was on hostA. In all cases, TERM is always set to "unknown" by the SCO machine. Am I missing something obvious, or is SCO's rlogind/login combo broken? Thanks for any help. --jim ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651
cliffb@cjbsys.bdb.com (cliff bedore) (01/13/91)
In article <778@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: >I have recently discovered that when doing an "rlogin" from hostA to >hostB (where hostA is any TCP/IP machine, and hostB is an SCO Xenix >machine, running TCP/IP 1.0.1h), that hostB does not correctly set >TERM to whatever value it was on hostA. In all cases, TERM is always >set to "unknown" by the SCO machine. > >Am I missing something obvious, or is SCO's rlogind/login combo >broken? > >Thanks for any help. >--jim >------------- >James B. O'Connor jim@tiamat.fsc.com >Ahlstrom Filtration, Inc. 615/821-4022 x. 651 It's broken on mine also. I have inserted the following line in my .login which at least offers me my favorite terminal if the system doesn't know what the terminal is. set term = (`tset -m ansi:ansi -m :\?ansi -r -S -I -Q`) (replace ansi with your favorite terminal.) Cliff
jim@tiamat.fsc.com (Jim O'Connor) (01/14/91)
In article <1991Jan13.000706.15034@cjbsys.bdb.com>, cliffb@cjbsys.bdb.com (cliff bedore) writes: > > It's broken on mine also. I have inserted the following line in my .login > which at least offers me my favorite terminal if the system doesn't know what > the terminal is. > > > set term = (`tset -m ansi:ansi -m :\?ansi -r -S -I -Q`) I had something in all my .profile's (I'm a ksh user), which is my I never noticed the problem. Recently, though, we started thinking about letting more of our non-programming users (i.e. secretaries, VP's, QC technicians, etc) take advantage of network logins for certain applications, and it was during the testing phase that I discovered it. Since we usually try to not make these type of users have to deal with such things as setting terminals types, I'm hoping there's a way to fix this. Thank you for your confirmation on being broken, though. Knowing that it happens to someone else will make it easier if I have to call SCO (i.e. maybe they'll believe it's a bug). ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651
lwj@cs.kun.nl (Luc Rooijakkers) (01/16/91)
In <779@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: >In article <1991Jan13.000706.15034@cjbsys.bdb.com>, cliffb@cjbsys.bdb.com (cliff bedore) writes: >> >> It's broken on mine also. I have inserted the following line in my .login >> which at least offers me my favorite terminal if the system doesn't know what >> the terminal is. >> >> >> set term = (`tset -m ansi:ansi -m :\?ansi -r -S -I -Q`) >I had something in all my .profile's (I'm a ksh user), which is my I never >noticed the problem. Recently, though, we started thinking about >letting more of our non-programming users (i.e. secretaries, VP's, >QC technicians, etc) take advantage of network logins for certain >applications, and it was during the testing phase that I discovered it. >Since we usually try to not make these type of users have to deal with >such things as setting terminals types, I'm hoping there's a way >to fix this. There is a way to fix this on SCO UNIX; this may apply to SCO XENIX as well (I haven't tested it there). What happens is that (on SCO UNIX at least) rlogind passed the correct TERM environment variable to the login shell, but it is ignored by tset (which you probably have somewere in /etc/profile). The secret is hidden in a paragraph in the manual entry of tset, which says something like When no arguments are specified, tset reads the terminal type from the TERM environment variable and re-initializes the terminal, and performs initialization of mode, environ- ment and other options at login time to determine the termi- nal type and set up terminal modes. (this is from the SunOS manuals, but the XENIX manuals say something similar). What I found out was that the inclusion of any terminal type *argument* or -m *option* causes tset to ignore TERM and use /etc/ttytype. Thus, what I did was to do all the fancy mapping stuff only if the user was not logging in from a pseudo tty (i.e., if `tty` did not match /dev/ttyp*). This fixed it for our case (Sequent rlogin to SCO UNIX). NB. It is sometimes helpful in cases like this to include a 'set' command in /etc/profile, to see what is coming in and who destroys it. Hope this helps. -- Luc Rooijakkers Internet: lwj@cs.kun.nl Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj University of Nijmegen, the Netherlands tel. +3180652271
jim@tiamat.fsc.com (Jim O'Connor) (01/18/91)
In article <2642@wn1.sci.kun.nl>, lwj@cs.kun.nl (Luc Rooijakkers) writes: > > There is a way to fix this on SCO UNIX; this may apply to SCO XENIX > as well (I haven't tested it there). What happens is that (on SCO UNIX > at least) rlogind passed the correct TERM environment variable to the > login shell, but it is ignored by tset (which you probably have somewere > in /etc/profile). The secret is hidden in a paragraph in the manual Nope. The reason I never noticed the problem was that I *DID* have tset in my .profile. Our normal users don't have tset in .profile, and it's not in /etc/profile, since they expect us (the administrators) to make sure the term type gets set for them. It was when I started testing things as a normal user that I noticed that the terminal type always came up "unknown". > NB. It is sometimes helpful in cases like this to include a 'set' > command in /etc/profile, to see what is coming in and who destroys it. I added "env" as the very first command in /etc/profile and TERM always equals "unknown" when rlogin'ing into the Xenix box. > Hope this helps. Nope, but I do appreciate the effort. ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651