jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/18/88)
I have finished [ ha! ] the login clone I've been working on. The package includes replacements for login, su and passwd. It has some interesting feature you might want to play with, here is a short list: - Shadow password file. - Password aging. - Login-time environmental variable setting. - Optional mandatory passwords for blank entries. - Restricted root logins. - Optional mailbox checking. - Optional message of the day printing. - .hushlogin functionality. - Last login time accounting ala' lastlog. - su use accounting. - Login time setting of ulimit, umask and nice. - Terminal messages configurable on or off. - Subsystem root logins. All of the more modern logins have most these features, but now you can have all of them. And since it is source, you can add your own. Anyone who wants to beta test a copy [ first couple requests only ] send a reasonable address, and I'll ship you a copy of the shar file. It currently compiles cleanly on Xenix, so let's hear from other systems. -- John F. Haugh II +----------Quote of the Week:---------- VoiceNet: (214) 250-3311 Data: -6272 | "Okay, so maybe Berkeley is in north- InterNet: jfh@rpp386.Dallas.TX.US | ern California." -- Henry Spencer UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
johnb@lakesys.lakesys.com (John C. Burant) (12/28/89)
Okay, since talk here is involving start-ups, and I have a problem slightly related to .profiles (and .logins), I'll get my feet wet in this group. I'm using a SCO UNIX/386, csh (heck, it doesn't work with ksh either), and am having trouble setting up my terminal emulation correctly. Everything here has been tested with ksh and csh, so please don't direct me to try the same with the other shell. If, when I login, I accidentally type the wrong terminal emulation to use (ex. mistype: vt199 instead of vt100), the system won't find it in termcap and will say unknown and all's good. But if I try to set it again to a terminal emulation with EVERYTHING from the manual pages of tset, termcap, etc. (exhaustive search of them), nothing will actually get the system to work (i.e., can't run things that require a good emul), and even if I do a csh .login or a . .profile, the system won't set it correctly, even going trough the whole login procedeure a second time (exececuting those .profile or .login files). Now, it will act as if it did set (the system will even SAY IT DID!), but the TERMCAP variable is blank, as well as the TERM variable. Hmph.. I've talked to the local unix guru (well...) and he's had the exact same problem and it doesn't work. I know UNIX and terms don't mix (polar and nonpolar?) very well, but when it works from login and not from executing the .login or .profile file, something is screwed up. Thank ye. -John -- John C. Burant | johnb@lakesys.lakesys.com Glendale, Wisc | johnb@lakesys.UUCP (414) 228-7915 | uunet!marque!lakesys!johnb
sukthnkr@phoenix.Princeton.EDU (Rahul Sukthankar) (12/28/89)
In article <1471@lakesys.lakesys.com> johnb@lakesys.lakesys.com (John C. Burant) writes: >Okay, since talk here is involving start-ups, and I have a problem slightly >am having trouble setting up my terminal emulation correctly. Everything >here has been tested with ksh and csh, so please don't direct [after entering the wong term type] >I do a csh .login or a . .profile, the system won't set it correctly, even >going trough the whole login procedeure a second time (exececuting those >.profile or .login files). I notice that you "csh .login". This will only make changes in a COPY of the variables. Do the following: a) source .cshrc (you might be setting stuff here too) b) source .login and enter the correct term type. Hopefully this will work. >-John -- Rahul Sukthankar (sukthnkr@phoenix.princeton.edu) ^ |__ goes down in flames, rises from the ashes.
bb@beach.cis.ufl.edu (Brian Bartholomew) (12/28/89)
In article <1471@lakesys.lakesys.com> johnb@lakesys.lakesys.com (John C. Burant) writes: ...[deleted]... >I'm using a SCO UNIX/386, csh (heck, it doesn't work with ksh either), and >am having trouble setting up my terminal emulation correctly. Everything >here has been tested with ksh and csh, so please don't direct me to try the >same with the other shell. > >If, when I login, I accidentally type the wrong terminal emulation to use >(ex. mistype: vt199 instead of vt100), the system won't find it in termcap >and will say unknown and all's good. But if I try to set it again to >a terminal emulation with EVERYTHING from the manual pages of tset, termcap, >etc. (exhaustive search of them), nothing will actually get the system >to work (i.e., can't run things that require a good emul), and even if >I do a csh .login or a . .profile, the system won't set it correctly, even >going trough the whole login procedeure a second time (exececuting those >.profile or .login files). Now, it will act as if it did set (the system >will even SAY IT DID!), but the TERMCAP variable is blank, as well as >the TERM variable. ...[deleted]... >John C. Burant | johnb@lakesys.lakesys.com >Glendale, Wisc | johnb@lakesys.UUCP >(414) 228-7915 | uunet!marque!lakesys!johnb I have used SCO XENIX 286 and 386, versions 2.2.1 to 2.2.3 (?) daily for a year and a half. The whole system was vanilla SCO, and I used csh as my login shell. As I remember, when you logged in, tset was set up to prompt you about the term type, if it didn't recognize what port you were logging in from. If you hit return on the suggested type, it worked. If you entered a legal type and hit return, it worked. If you entered an undefined type, it bombed with some inappropriate error message (something about indexing off the end of an array), and the type was not set. However, whenever I wanted to change the term type in the middle of a login session, I just changed TERM and TERMCAP directly, thusly: % setenv TERMCAP "" % setenv TERM wy60 This always worked. With the number of I/O bugs we found with the system in general, I am not suprised that tset is failing on you. As a historical note, we discovered that this machine had a working termcap entry for a Radio Shack model 100 notebook computer, doubtless because XENIX was originally a Microsoft port for a TRS-something business computer. This was good, because we were using m100's as remote terminals and barcode-entry machines on a factory floor. Good luck with the XENIX. I do BSD now. -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb University of Florida Internet: bb@beach.cis.ufl.edu
cpcahil@virtech.uucp (Conor P. Cahill) (12/28/89)
In article <1471@lakesys.lakesys.com>, johnb@lakesys.lakesys.com (John C. Burant) writes: > Hmph.. I've talked to the local unix guru (well...) and he's had the exact > same problem and it doesn't work. > I know UNIX and terms don't mix (polar and nonpolar?) very well, but when > it works from login and not from executing the .login or .profile file, > something is screwed up. If you are running your .profile/.login which sets the TERM and/or TERMCAP variable appropriately when you login, you must be running it wrong when you try to do it again. If you asked you local unix guru about it and he didn't know what the problem was, he isn't much of a guru. The problem is either you .profile does not set the environment variable if it is already set or you are not "sourcing" the .profile. By sourcing the .profile I mean typing ". .profile" as opposed to ".profile". (This asumes you are running a version of unix that is > V6 ). If you don't source the .profile, it runs as a sub-shell and sets the environment variables in the sub-shell, not your login shell. As soon as the sub-shell exits, those variables are gone. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
drich@.UUCP (Dan Rich) (12/28/89)
In article <1471@lakesys.lakesys.com> johnb@lakesys.lakesys.com (John C. Burant) writes:
... Problem with setting terminal type ...
Before I go off into an answer for this, does anyone know of a way to
auto-identify a terminal at login? I know that this can be done,
because years ago, I used such a program under VMS. It would
recognize a VT100, TVI920, ADM3a, and several other terminals. Here,
we use vt100, vt220, and at386 (the ISC 386/ix console). It would be
nice if I could find out what kind of terminal the user is without
asking...
Note: All commands in () are for ksh.
First of all, when you execute a .login (.profile) with csh (ksh), it
won't return any of the variables to the envoirment. The command you
want it source (.) as in:
% source ~/.login (. ~/.profile)
If you want to reset the terminal without running your login script,
just type the following sequence of commands:
% tset -sQ <terminal-name> > .temp
% source .temp (. .temp)
% rm .temp
The problem is, that tset outputs the TERM= and TERMCAP= to standard
out. This is supposed to be interpreted by the shell, but for some
reason this never seems to work. I have used the above three lines in
my .login for the last couple of years, and have never had a problem.
--
Dan Rich | ARPA: drich%dialogic@uunet.uu.net
UNIX Systems Administrator | UUCP: uunet!dialogic!drich
Dialogic Corporation | - Time is an illusion. Lunchtime, doubly so. -
(201) 334-1268 x213 | Douglas Adamsvalsee@qat.UUCP (12/29/89)
> > Hmph.. I've talked to the local unix guru (well...) and he's had the exact > > same problem and it doesn't work. > > I know UNIX and terms don't mix (polar and nonpolar?) very well, but when > > it works from login and not from executing the .login or .profile file, > > something is screwed up. > > [...] > The problem is either you .profile does not set the environment variable > if it is already set or you are not "sourcing" the .profile. By sourcing > the .profile I mean typing ". .profile" as opposed to ".profile". (This > asumes you are running a version of unix that is > V6 ). > > If you don't source the .profile, it runs as a sub-shell and sets the > environment variables in the sub-shell, not your login shell. As soon as > the sub-shell exits, those variables are gone. > yup. as a note, use the "source" statement in csh to accomplish the same thing in that shell, i.e. "source .login" instead of ".login". -- valerie see ..texbell!techsup!qat!valsee seev@techsup.lonestar.org
valsee@qat.UUCP (12/29/89)
Written by dialogic.UUCP!drich in qat:comp.unix.wizards: > If you want to reset the terminal without running your login script, > just type the following sequence of commands: > % tset -sQ <terminal-name> > .temp > % source .temp (. .temp) > % rm .temp > > The problem is, that tset outputs the TERM= and TERMCAP= to standard > out. This is supposed to be interpreted by the shell, but for some > reason this never seems to work. I have used the above three lines in > my .login for the last couple of years, and have never had a problem. one can get around this in Bourne shell by using the eval statement and command substitution, i.e. " eval `tset -s -Q....` ". i don't know off the top of my head if there is an equivalent for csh; i certainly can't remember one at the moment. of course, the above capture method works perfectly, so i suppose one could ask "why mess with success?" -- valerie see ...texbell!techsup!qat!valsee seev@techsup.lonestar.org
jik@athena.mit.edu (Jonathan I. Kamens) (12/31/89)
In article <1400002@qat> valsee@qat.UUCP writes: >one can get around this in Bourne shell by using the eval statement and >command substitution, i.e. " eval `tset -s -Q....` ". i don't know off >the top of my head if there is an equivalent for csh; i certainly can't >remember one at the moment. Strangely enough, the command in csh would be, "eval `tset -s -Q...`". The man page for csh claims that the eval command for csh is "as in sh(1)." One additional note, in response to the post to which Valerie was responding: The commands output by tset are not supposed to be magically executed by the shell in some way. They are *supposed* to be evaluated by the user, either by saving them to a file and sourcing it, or by the more efficient method of using eval. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
valsee@qat.UUCP (01/02/90)
Written 9:27 pm Dec 30, 1989 by bloom-beacon.UUCP!jik: > >one can get around this in Bourne shell by using the eval statement and > >command substitution, i.e. " eval `tset -s -Q....` ". i don't know off > >the top of my head if there is an equivalent for csh; i certainly can't > >remember one at the moment. > > Strangely enough, the command in csh would be, "eval `tset -s > -Q...`". The man page for csh claims that the eval command for csh is > "as in sh(1)." as Jonathan is the second to have pointed this out, i will mention that evidently not all csh implementations have eval built into them. none of the unix/xenix variants in use at this site support eval in their supplied csh's... a silly thing to leave out, but there are worse. the only thing good i can say about it is that in all cases there was no claim that eval was supported in the respective manual pages supplied with the systems. additionally, the tset man page documents the "trap output in temporary file, then execute the temp file" method of using tset -s instead of making mention of using the eval approach. but i've wasted more than enough of everyone's time on this... valerie see ...texbell!techsup!qat!valsee seev@techsup.lonestar.org