nash@sdsu.UUCP (Ron Nash) (06/25/87)
I am interested in setting up a system wide .login that will execute prior to a users .login under /bin/csh. I am familiar with the Borne shells execution of /etc/profile; however, I need this for the csh. We do not have source so patches to /bin/csh or /bin/login are not of interest. Does anybody have a shell script or a program that can be run inplace of /bin/csh that will allow this and exec /bin/csh as if exec'ed by /bin/login? The system is a Harris HCX-7 running HCX/UX V2.2 which is an AT&T System 5 V2.2 clone with many Berkley 4.2 features. Thanks in advance! Ron Nash San Diego State University (619)265-4363 sdscvax!sdsu!nash
jfh@killer.UUCP (John Haugh) (06/26/87)
In article <2626@sdsu.UUCP>, nash@sdsu.UUCP (Ron Nash) writes: > I am interested in setting up a system wide .login that will execute > prior to a users .login under /bin/csh. I am familiar with the Borne We have a Plexus P/60 running something like Unix, the csh startup file seems to be /etc/cshprofile. I don't know if this is standard, you might want to try it though. Or you could run strings on csh and see what neat file names show up. When in doubt - hack it out... - John. Disclaimer: No disclaimer. Whatcha gonna do, sue me?
V2002A%TEMPLEVM.BITNET@wiscvm.wisc.EDU (07/06/87)
I've tried to set up a shell script in the systems /etc/profile
to read user input and set the terminal type accordingly, but I ran into
a problem with the TERM variable being exported to the login shell and
not to the users shell. A system wide .login might run into similar
'environment' problems. I'm running System V (ver 3.0) on a 3B2-400.
An ATT technician tells me there is a way to fix this. Any ideas
on this or the system wide .login??
Andy Wing <V2002A@TEMPLEVM.BITNET>gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/06/87)
In article <8176@brl-adm.ARPA> V2002A%TEMPLEVM.BITNET@wiscvm.wisc.EDU writes: >a problem with the TERM variable being exported to the login shell and >not to the users shell. /etc/profile, as well as the user's .profile, is "sourced" by the login Bourne shell, that is, it is processed IN THE CONTEXT OF THE LOGIN SHELL and therefore affects its variables. To make a shell variable "known" to subshells, it must be EXPORTED (which puts it into the environment of the login shell, so it is inherited by subprocesses). For example: TERM=tty5620 export TERM or even TERM=tty5620 export TERM (which makes use of a different "trick", even though it looks similar).
rwhite@nu3b2.UUCP (Robert C. White Jr.) (07/07/87)
In article <8176@brl-adm.ARPA>, V2002A%TEMPLEVM.BITNET@wiscvm.wisc.EDU writes: > > I've tried to set up a shell script in the systems /etc/profile > to read user input and set the terminal type accordingly, but I ran into > a problem with the TERM variable being exported to the login shell and > not to the users shell. A system wide .login might run into similar > 'environment' problems. I'm running System V (ver 3.0) on a 3B2-400. > An ATT technician tells me there is a way to fix this. Any ideas > on this or the system wide .login?? > > Andy Wing <V2002A@TEMPLEVM.BITNET> this is our /etc/profile, it does the TERM bit. [If you use a table replace the "read"s with "awk"s against your table. The added code is in there twice, but it only runs once per invocation [either by login exec(ing) sh with the -sh name or su -. # @(#)profile 1.5 /sccs/src/cmd/sadmin/etc/s.profile # The profile that all logins get before using their own .profile. trap "" 2 3 export LOGNAME . /etc/TIMEZONE # Login and -su shells get /etc/profile services. # -rsh is given its environment in its .profile. case "$0" in -su ) export PATH stty ixon -ixany # <<<<< ADDED HERE >>>>>>>>> stty erase "^H" echoe echo "Enter Terminal Type (default = 610): \c" read TERM echo "Terminal Type Set to: ${TERM:=610}" export TERM # <<<<< To HERE >>>>>>>> ;; -sh ) export PATH stty ixon -ixany # <<<<<< and AGAIN >>>>>>>>> stty erase "^H" echoe echo "Enter Terminal Type (default = 610): \c" read TERM echo "Terminal Type Set to: ${TERM:=610}" export TERM # <<<<< To HERE >>>>>>>> # Allow the user to break the Message-Of-The-Day only. trap "trap '' 2" 2 cat -s /etc/motd trap "" 2 if mail -e then echo "you have mail" fi if [ ${LOGNAME} != root ] then news -n fi ;; esac umask 022 trap 2 3
rjd@tiger.UUCP (07/08/87)
> I've tried to set up a shell script in the systems /etc/profile > to read user input and set the terminal type accordingly, but I ran into > a problem with the TERM variable being exported to the login shell and > not to the users shell. A system wide .login might run into similar > 'environment' problems. I'm running System V (ver 3.0) on a 3B2-400. > An ATT technician tells me there is a way to fix this. Any ideas > on this or the system wide .login?? > > Andy Wing <V2002A@TEMPLEVM.BITNET> The users login shell and users shell are the same shell. All you need to do is to remember to export the enviroment variable, e.g.: ---from a sample /etc/profile:----------- /bin/echo "Enter terminal type: \c" read TERM export TERM ----------------------------------------- simple, huh? Randy Davis UUCP:(ihnp4!)3b2fst!randy
kai@ihlpa.ATT.COM (Irwin) (07/18/87)
In article <142700009@tiger.UUCP>, rjd@tiger.UUCP writes: > > > I've tried to set up a shell script in the systems /etc/profile > > to read user input and set the terminal type accordingly, but I ran into > > a problem with the TERM variable being exported to the login shell and > > not to the users shell. A system wide .login might run into similar > > 'environment' problems. I'm running System V (ver 3.0) on a 3B2-400. > > An ATT technician tells me there is a way to fix this. Any ideas > > on this or the system wide .login?? > > > > Andy Wing <V2002A@TEMPLEVM.BITNET> > > The users login shell and users shell are the same shell. All you need to > do is to remember to export the enviroment variable, e.g.: > ---from a sample /etc/profile:----------- > /bin/echo "Enter terminal type: \c" > read TERM > export TERM > ----------------------------------------- > simple, huh? > > Randy Davis UUCP:(ihnp4!)3b2fst!randy I used to use a little shell script called "termlo" that I wrote that would look up hardwired terminal types in a "MAP" and only prompt for a terminal if it was a dial up port ( actually it would "best guess" the default for dial-ups too.) the "MAP" looked somthing like: /dev/console::4425:system console:computer center /dev/tty001::vt100:user terminal:room 514 /dev/tty010:bob:vt100:dial-up:bobs PC /dev/tty010:bobo:wyse30:dial-up:bobos desk ...etc so console would always be an AT&T 4425, tty001 always a vt100, dialups based on the user id so in /etc/profile: export TERM TTY=`tty` TERMLO=`grep $TTY /etc/termmap | cut -d: -f1-3` USER=`echo "$TERMLO" | grep $LOGNAME | cut -d: -f2` TERM=`echo "$TERMLO" | grep "$TTY:$USER:" | cut -d: -f3` if test -n "$USER" then echo "Enter Terminal Type [Default $TERM]:\c" read term TERM=${term:-$TERM} fi and in a shell script called termlo: echo "TTY\t\tUSER\t\tUSE\t\tDESCRIPTION" echo sed 's/:/<TAB><TAB>/g' < /etc/termmap I'm trying to do this by memory so i won't promise this will work with out some debugging but it worked very well and in the invironment it was used it generated correct defaults MOST of the time, and the "termlo" command gave a pretty good indication as to where the login was comming from (termlo was more elaberate than I show but I don't have the script handy) Ken A. Irwin AT&T Bell Labs, Naperville IHP 1a332 (312) 416-4485
jdia@osiris.UUCP (Josh Diamond) (07/20/87)
In article <4668@ihlpa.ATT.COM>, kai@ihlpa.ATT.COM (Irwin) writes: > In article <142700009@tiger.UUCP>, rjd@tiger.UUCP writes: > > > > > I've tried to set up a shell script in the systems /etc/profile > > > to read user input and set the terminal type accordingly, but I ran into > > > a problem with the TERM variable being exported to the login shell and > > > not to the users shell. A system wide .login might run into similar > > > 'environment' problems. I'm running System V (ver 3.0) on a 3B2-400. I have a program called qterm which gets the type of the terminal by asking the terminal hardware to identify itself. Currently it works with vt52/10x/2x0 as well as a bunch of terminal emulators. It is easy to modify it to allow additional terminals. * qterm - Query Terminal * * qterm is used to query a terminal to determine the name of the terminal. * This is done by sending a fairly universal string "\33Z" to the terminal, * reading in a response, and comparing it against a master table of responses * and names. The "name" printed to standard output should be one found in * the termcap(5) database. * * Putting a line in your .login files such as: * * setenv TERM `qterm` * * will set your terminal type automagically. If anyone wants this, I could email it to them. If there are enough requests I can try to post it. A serious offer from Spidey!!! -- We're on an express elevator to hell -- GOING DOWN!!! /\ Josh /\ THRILL //\\ .. //\\ SEEKERS A message from Spidey, and the Spidey Team. ----->>> //\(( ))/\\ UNITE!!! Available via UUCP: ...[seismo,mimsy]!jhu!osiris!jdia / < `' > \
rjd@tiger.UUCP (07/20/87)
> I used to use a little shell script called "termlo" that I wrote that would > look up hardwired terminal types in a "MAP" and only prompt for a terminal > if it was a dial up port ( actually it would "best guess" the default for > dial-ups too.) > > [ description of method deleted ] Yeah, on my system, for all hardwired terminals, I just put a case statement off the output of the 'tty' command in /etc/profile with the default prompting the user or using his default, using the type of script I already posted. Randy Davis UUCP: ...(ihnp4!)3b2fst!randy
mcooper@castor.usc.edu (Michael A. Cooper) (07/21/87)
In article <1317@osiris.UUCP> jdia@osiris.UUCP (Josh Diamond) writes: >I have a program called qterm which gets the type of the terminal by >asking the terminal hardware to identify itself. Currently it works >with vt52/10x/2x0 as well as a bunch of terminal emulators. It is easy to >modify it to allow additional terminals. > ... >If anyone wants this, I could email it to them. If there are enough requests >I can try to post it. > I really hate these plugs, but I really don't wish old, non-official copies of qterm's being distributed, so... My latest version of qterm was sent to comp.sources.unix a few weeks ago and should be appearing "Real Soon Now" (right, Rich?). If you have Internet access, then you can retrieve a copy via anonymous ftp from oberon.USC.EDU in pub/qterm.shar. Michael A. Cooper, University Computing Services, U of Southern California UUCP: {sdcrdcf, cit-vax}!oberon!mcooper BITNET: mcooper@uscvaxq ARPA: mcooper@oberon.USC.EDU PHONE: (213) 743-2957