bbh@whizz.UUCP (Bud Hovell) (09/09/88)
>In article <344@whizz.UUCP> bbh@whizz.UUCP (Bud Hovell) writes: >>On the 3B1/7300, '/etc/profile' has a trap statement that disables the <del> >>key, which is very desireable to have when you are working in Informix. >>After each 'trap' statement, remove the '2', and all terminals & the console >>have this function available. > >Huh? >Sounds like you screwed up your /etc/profile. I've got no problems with using >my delete key over here on my 3B1. The last line in my /etc/profile reads: > >trap 1 2 3 > >Which disables all the traps before ~me/.profile is invoked. >-- >John "C". Sucilla, A silicon based life form. If it's screwed up, John, then AT&T did the screwing - the script I was referring to wasn't my own backroom creation - it came with the year-old 3B1 that I bought, and has the official Death Star logo on the 3.51 discs, and is unaltered by the 'a' upgrade. It *is* possible that there are different scripts - I really don't know. But there are a total of 3 (three) trap statements in my script. It is version 1.7. The same came on my partner's 3B1, purchased in April. Is yours? Also, I am a bit unclear on your intended meaning when you describe how a 'trap 1 2 3' statement "disables" the traps - it specifically *enables* traps 1, 2, and 3 - trap 2 being the specific villain which must be removed in order that the interrupt NOT be trapped (that is, hit in the head) when you use the <del> key. (At least Kernighan thinks it works that way: see page 150 of The UNIX Programming Environment). Or are we RTFMing out of different hymnals? Below is an excerpt of the original script baptized by AT&T and unsullied by any of my subsequent changes. This should provide sufficient info for assessing whether 'profile' scripts on other machines are/are not likewise deliberately crippled: ============================================================================ #sccs "@(#)fndetc:profile 1.7" # # FILE: /etc/profile # Initialization script for all logins. # trap '' 1 2 3 set `who -r` if [ "$3" = "S" ] then sync;sync;sync /etc/killall ## Any shutdown procedures (such as slancard reset) can be ## put in /etc/shutdaemon, and will be executed without ## changing /etc/profile. . . <more stuff> . . TERM=adm3 else # A Remote Login trap "exit" 1 2 3 SHFLAG=0 PHRASE=" " ADDEDINFO=", '?' for help, or 'exit' to exit,\n" while true do . . <more stuff> . . set `df -t /` AVSPACE=`expr ${3}00 / $8` echo "\n ${AVSPACE}% of the storage space is available." cat /etc/motd #ATATE IS THE ENVIRONMENT VARIABLE FOR dBASE III ATATE=/usr/lib/dbase; export ATATE trap 1 2 3 ============================================================================ If Rick Calder (or other ATT UNIX PC guru) would like to step into this amateur discussion to offer the final word (this is mine), it would be fine by me. ::::::::::::::::::::::::: | | Bud Hovell | OVERTURE SYSTEMS CORP | (503) 636-3000 | Lake Oswego, OR | | | ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: | UUCP{attmail!, tektronix!tekgen!teksce!bucket!, pacbell!safari!}whizz!bbh | :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
bbh@whizz.UUCP (Bud Hovell) (09/09/88)
In a just-launched reply to John Sucilla, I said: >Also, I am a bit unclear on your intended meaning when you describe how a >'trap 1 2 3' statement "disables" the traps - it specifically *enables* traps >1, 2, and 3 - trap 2 being the specific villain which must be removed in >order that the interrupt NOT be trapped (that is, hit in the head) when you >use the <del> key. (At least Kernighan thinks it works that way: see page 150 >of The UNIX Programming Environment). > >Or are we RTFMing out of different hymnals? After myself re-reading Kernighan, I have to conclude that it is I who have a limited understanding of the 'trap' command. Also, I must disclaim the ability to assert what Kernighan - or anyone else - thinks about this subject, since my mind-reading ability is even more flawed than my knowledge of 'trap'. :-) However, I must stand by the basic facts offered: with the trap 2 command, my 610 terminal and console completely loose the <del> key function when they go into Informix SQL, and this problem is eliminated (with no apparent side effects) by removing them. (Informix disclaims any knowledge). Because I have just set up two other 7300 machines to dial into this database, it was also necessary to make the same adjustments to those scripts after the users complained about the absence of the <del> key - and couldn't get out of the program till I killed the process! After 'trap' changes were made, they have (like me) had no further problems. And, again, I invite anyone who knows to explain why these facts should be so. Kernighan notwithstanding. ::::::::::::::::::::::::: | | Bud Hovell | OVERTURE SYSTEMS CORP | (503) 636-3000 | Lake Oswego, OR | | | ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: | UUCP{attmail!, tektronix!tekgen!teksce!bucket!, pacbell!safari!}whizz!bbh | :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
jcs@tarkus.UUCP (John C. Sucilla) (09/11/88)
In article <346@whizz.UUCP> bbh@whizz.UUCP (Bud Hovell) writes: >>In article <344@whizz.UUCP> bbh@whizz.UUCP (Bud Hovell) writes: >>>On the 3B1/7300, '/etc/profile' has a trap statement that disables the <del> >>>key, which is very desireable to have when you are working in Informix. >>my delete key over here on my 3B1. The last line in my /etc/profile reads: >>trap 1 2 3 >>Which disables all the traps before ~me/.profile is invoked. >It *is* possible that there are different scripts - I really don't know. But >there are a total of 3 (three) trap statements in my script. It is version >1.7. The same came on my partner's 3B1, purchased in April. Is yours? Mine is version 1.5. I'm running 3.50 UNIX upgraded to 3.5.1.4. Mine also has a total of three trap's. >Also, I am a bit unclear on your intended meaning when you describe how a >'trap 1 2 3' statement "disables" the traps - it specifically *enables* traps >1, 2, and 3 - trap 2 being the specific villain which must be removed in >order that the interrupt NOT be trapped (that is, hit in the head) when you >use the <del> key. (At least Kernighan thinks it works that way: see page 150 >of The UNIX Programming Environment). > >Or are we RTFMing out of different hymnals? Yes, we are. I looked at the page you referenced in that book and saw that it explains how to set up traps but says absolutely nothing about how to turn them off. Look at sh(1) in your UNIX Users Manual, turn to the page that describes 'trap' and you will see the following: trap [arg] [n]... . . If arg is absent then all trap(s) n are RESET to to their original values. The last line in /etc/profile says: trap 1 2 3, which as I stated before, disables (resets, whatever you want to call it) the signals for hangup, interrupt and quit back to their default values which is "don't intercept them". >If Rick Calder (or other ATT UNIX PC guru) would like to step into this >amateur discussion to offer the final word (this is mine), it would be fine >by me. Are you mad at me? I was just trying to help... By the way, I'm no amateur. I've been working with UNIX for about seven years now. I'm willing to mail you a copy of my version 1.5 script since you apparently have a legal copy of 3B1 UNIX. If you want it, let me know. I think it's worth a try. If your problem with the delete key continues you would know that it wasn't /etc/profile thats giving you grief, the problem would have to be some other script thats getting executed after /etc/profile. I'd also like to see your version 1.7 script (I have a legal copy too), I'll try it over here and see if the same thing happens. Send it to me if you'd like. If it acts the same here I'll fix it and send it back to you. -- John "C". Sucilla, A silicon based life form. {att,chinet,ddsw1}!tarkus!jcs You have a better idea? Now's the time..
greg@csanta.UUCP (Greg Comeau) (09/12/88)
In article <349@whizz.UUCP> bbh@whizz.UUCP (Bud Hovell) writes: > > ...[ discussion of `trap' commands in /etc/profile in their influence on > Informix SQL ] ... > The three traps in my /etc/profile: 1) trap '' 1 2 3 2) trap "exit" 1 2 3 3) trap 1 2 3 look the same as yours. They mean: 1) ignore signals 1 (hangup), 2 (interrupt), and 3 (quit). 2) if signal 1, 2, or 3 is recieved, then run the `exit' command. 3) *reset* signals 1, 2, and 3 to the original values they had when the given shell was entered. respectively. This does not appear to negate anything said by Kernighan in The UNIX Programming Environment. ?? Also, note that (3) does not disable *or* enable signals specified, something like (1) or `trap "" 1 2 3' does that. (3) only serves to reset... > However, I must stand by the basic facts offered: with the trap 2 command, > my 610 terminal and console completely loose the <del> key function when they > go into Informix SQL, and this problem is eliminated (with no apparent side > effects) by removing them. (Informix disclaims any knowledge). Fine. If that is the case, then Informix SQL expect the signals to be a certain way (and it can check them and do certain thing based on their values which *seems* to be the case here... why I don't know..). Do not however change this in /etc/profile, but change it in each user's .profile file. Or better yet, make a shell script that does the correct trap and then `exec's informix and tell the users not to run informix directly. You can enforce this by renaming the original binary...
bbh@whizz.UUCP (Bud Hovell) (09/14/88)
In article <237@tarkus.UUCP>, jcs@tarkus.UUCP (John C. Sucilla) writes: <deleted: helpful pointers from John to me on where to find info on how to use traps correctly, and offering to help by swapping/fixing /etc/profile scripts> > Are you mad at me? I was just trying to help... By the way, I'm no amateur. > I've been working with UNIX for about seven years now. No, John, as the evidence will now show, I have only myself to be angry with, and certainly not you. As it turns out, you have been right on all counts, and I most certainly *did* screw up - not just once, but in sufficiently numerous ways to be rightly chagrined. To put it mildly. Given that that is so, I am glad you pressed the point, since my original posting would fully qualify as 'disinformation' that would cause even the KGB to blush with envy. The reference to 'amateur' was directed more at me than you, but it obviously missed the mark widely. I hope that apology - along with the following explanation of how this all transpired - will suffice. > I'm willing to mail you a copy of my version 1.5 script since you apparently > have a legal copy of 3B1 UNIX. If you want it, let me know. I think it's > worth a try. If your problem with the delete key continues you would know > that it wasn't /etc/profile thats giving you grief, the problem would have to > be some other script thats getting executed after /etc/profile. > > I'd also like to see your version 1.7 script (I have a legal copy too), I'll > try it over here and see if the same thing happens. Send it to me if you'd > like. If it acts the same here I'll fix it and send it back to you. > -- > John "C". Sucilla Thank you. Your offer is more gracious than is deserved. While I can offer no reasonable excuse for what follows, I feel duty-bound to retract bad information that I put out, now that I've had a bit of time to reconstruct events: First, what prompted me to make the original posting was an event that occurred the other day when I tied in two other sites to my database thru a shell script that is executed on logon and allows several menu options, one of which is to call an appropriate Informix user menu, and then (after completing a session) depart gracefully. Both of these machines are 7300/3B1s, running the same OS as mine (3.51a). After the linkup, I immediately got calls from both of these users saying that they weren't able to get their <del> keys to work when they entered into the database under terminal emulation. They are both using their consoles, and have no terminals. (On my machine, I my 610 the terminal almost exclusively, for reasons that don't matter here). "OH, yeah", I then said to myself, "I forgot that I had the same problem and had to make a change to the 'trap' statements in the profile script in order to clear it." 'Checked my script, went and changed theirs to match, and it suddenly occurred to me that others might want the same info - so I posted the original notice (God help me :-) and went blazing on into early morning with other tasks. What I had forgotten was that a change *had* been made to my original script (back-when) that allowed login on my 610 terminal without the need for my manually telling it (every dratted time!) that the tty000 terminal was a 610. And what I didn't know was that this change (somehow!) got copied over into the "original" copy that I keep on file, which I thought to be the virgin out -of-the-box version 1.7 profile that came with the machine. So I thought I was working with the original. Which is what I told you. Which was dead wrong! (My errors were by now compounding geometrically). And here was that change (in context) that actually *had* been made to the /etc/profile script: ---------------------------------------------------------------------- ####################### ALL VANILLA FROM TOP ######################### . . . NAME=`tty` if [ \( "`expr $NAME : '/dev/w' `" != "0" -o \ "`expr $NAME : '/dev/sys' `" != "0" \) ] then # A Console Window TERM=s4 elif [ "`expr $NAME : '/dev/con' `" != "0" ] then # A Windowless Console TERM=adm3 ######################### THIS WAS ADDED ############################# # Entry for system with 610 Terminal on tty000: elif [ "`expr $NAME : '/dev/tty000' `" != "0" ] then # A 610 Terminal TERM=610 #################### BACK TO VANILLA, HEREAFTER ###################### else # A Remote Login trap "exit" 1 2 3 SHFLAG=0 . . . ---------------------------------------------------------------------- But, even though I then no longer had to log in the terminal name, suddenly the <del> key on the terminal wouldn't work in INFORMIX. (It seems to me this occurred *only* in that application, now, but am now unwilling to swear to much of anything). Same problem on the console, as I recall. The "fix" - made by trial and error - was to remove the trap 2 - and everything worked! That problem solved, I was then free to move on to far more prodigious mischief-making during the intervening months until the other day :-). Anyhow, mia culpa - I blew it big-time with unclear recollection and presen- tation of the "facts". Sorry this took excessive bandwidth on the net. John, I will call or E-mail you in a few days to take you up on your offer, after I can get some other things completed. And maybe get a chance to look at the script more closely and do some testing, in light of the information you already have offered. At least hereafter my ignorance needn't provide the source of (admittedly limited) public amusement :-). ::::::::::::::::::::::::: | | Bud Hovell | OVERTURE SYSTEMS CORP | (503) 636-3000 | Lake Oswego, OR | | | ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: | UUCP{attmail!, tektronix!tekgen!teksce!bucket!, pacbell!safari!}whizz!bbh | :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::