trb (08/28/82)
Maybe this should go in net.trivia, it seems obscure.
This is everything I always wanted to ask about getty but was
previously afraid or too lazy to ask.
4.1bsd getty.c has some weird code in it.
First of all, right at the top, there are two signal calls commented out:
/*
signal(SIGINT, 1);
signal(SIGQUIT, 0);
*/
Why were they there, why are they commented out?
There are table entries for Interdata consoles and LSI chess
terminals. I bet the LSI chess terminal works on all of one cpu and I
have never heard of anyone on USENET running on an Interdata or Perkin
Elmer machine. (Those P/E machines look so HOT in the ads, howcome no
one on USENET has one?) Do these beasts in fact exist, running UNIX
processes for humans on Earth? Let yourselves be known! (Take me to
your leader?)
Then there's this bit of sorcery in the prompt/read loop:
if (tmode.sg_ospeed > B1200)
puts("\n\r\n\r");
else
puts("\n\r\r\r\r\r\n\r\r\r\r\r");
puts(myname);
puts("\n\r\r\r\r");
puts(tabp->message);
/*
* Wait a while, then flush input to get rid
* of noise from open lines
*/
sleep(1);
stty(0, &tmode);
When I hit a carriage return and try to log in, it eats the first few
characters of my login name. The comment says that it's trying to get rid
of line noise. Is this behavior worthwhile?
I used to have a problem that if I logged into the console with ALL
CAPS (like when Mr DEC Fieldservice leaves caps locked on the LA120)
getty would go into an infinite loop which could only be killed from
another terminal. Anyone ever see this?
I would like it if my dialups hung up on last close. I believe that I
properly configured my 4.1bsd kernel to perform this function, but it
only seems to work SOMETIMES. Has anyone else had this experience and
is it tied to getty?
Looking for clues,
Andy Tannenbaum Bell Labs Whippany, NJ (201) 386-6491JIM@Washington@sri-unix (09/13/82)
From: Jim Rees <JIM@Washington> Date: 10 Sep 1982 1023-PDT Getty does indeed have bugs. The pause to throw out line noise is necessary in some cases, but it has been implemented wrong. The line puts(tabp->message) or whatever should go after the delay and stty, so that when the "login:" prompt comes out you know it is safe to start typing. I don't know the reason for the commented calls to signal. There are indeed Perkin-Elmer systems running real live Unix. I claim to have installed the first v7 Unix on a P-E outside of Bell in 1979. There are at least two implementations; the one that Bell refuses to release, which uses the portable C compiler, and the one from Australia, which uses a ported Ritchie compiler. P-E bought the Australian version, made some mods to it, incorporated a lot of Berkeley stuff (including the C shell), and now will sell it to you, too. The reason you never see P-E machines on Usenet is that uucp has bugs in it which prevent it from working on a P-E machine, and no one has bothered to try to fix it (that I know of). We have two Perkin-Elmer Unix systems here at University of Washington. -------
swatt (09/14/82)
This is really more about Perkin Elmer UNIX than getty.c. At
least ONE P-E UNIX installation has fixed the uucp bugs
mentioned. No less than The Wollongong Group itself in the SF
Bay area is reachable via UUCP from us (ittvax). Their machine
name is "twg". They are not running news as the last time I
talked to them they didn't have the disk space to support it.
=================================================================
>From twg!gwg Thu Apr 29 11:17:27 1982
Date: Tuesday, 27 Apr 1982 13:39-PST
To: ittvax!swatt
Cc:
Subject: TWG Personnel
Alan -
This is as good chance as any to clean up the names of the
Wollongong personnel.
Here is an updated list with corrected spellings and
responsibilities. (Note the addition of Gordon, Mike overlooked him.)
mail address Name Responsibility
============ ==== ==============
twg!mike Michael Bourke Customer Support
twg!dan Dan Ladermann Dir. of Customer Support
twg!gary Gary Gorgen Dir. of Development
twg!gwg Gene Garbutt Language support
twg!betty Betty Forster Configuration Mgmt.
twg!gww Gordon W Waidhofer UNIX kernel & utilities
- Gene
=================================================================
- Alan S. Watt
([decvax!]ittvax!swatt)JIM@Washington@sri-unix (09/14/82)
From: Jim Rees <JIM@Washington> Date: 10 Sep 1982 1508-PDT Oh, yes, I forgot to tell you about the upper case bug. If you have version 4.3 of Berkeley Unix getty.c (the number refers to SCCS, not the successor of 4.1bsd) there is a line something like: *np = tolower(np); This is obviously wrong. It should be: *np = tolower(*np); I can't remember right now if the first or second "np" was missing the "*", but this could account for getty looping when you try to log in on an upper case terminal. This bug is missing from 4.2 and before, which simply wouldn't let you log in upper case. -------
perry.gatech@Udel-Relay@sri-unix (09/15/82)
From: Perry Flinn <perry.gatech@Udel-Relay> Date: 10 Sep 82 17:13:19-EDT (Fri) Regarding Andy Tannenbaum's message of 27 Aug 82: In order to get a dialup line to hangup on logging out someone has to issue the TICOHPCL ioctl code for the line. This can be done by getty or by login (the latter might be preferable since there is already special-case code there for dialup lines). It is my impression, though I haven't taken the time to verify it, that once this has been done for a particular line, it remains in effect for that line forever; there is no corresponding ioctl command to disable the feature. This may account for the inconsistent behavior mentioned. An alternate solution is to modify the device driver to enable the HUPCLS feature by default. In fact, the dz driver in 4.1bsd contains a line in the dzopen() function to do just that, though the line is commented out. (Another curiosity!) Of course, it is presumed that the cable running from the distribution panel to the modem actually carries the modem control signals (DTR in particular) and that they are not simply jumpered in the connectors.
v.wales@Ucla-Security@sri-unix (09/15/82)
From: v.wales at Ucla-Security (Rich Wales) Date: 11 September 1982 1442-PDT (Saturday) Here in the UCLA Computer Sci. Dept., we took out the "sleep" which purports to help get rid of noise on the line. As far as I am aware, we have never had any problems as a result of doing this. -- Rich
JIM@Washington@sri-unix (09/20/82)
From: Jim Rees <JIM@Washington> Date: 16 Sep 1982 0658-PDT I can beat a dead horse as well as anyone. I will never understand why the people who install rs-232 lines insist on being so lazy. The reason I never saw the ringing problem is that the systems I use carry the necessary status lines. And no, you don't need 8 of them, just one extra (DCD) will do. Besides being the correct way to wire your terminal, it is very convenient for a couple of reasons. One is that it solves the ringing problem. Another is that if you get yourself hopelessly hung up in something, you don't have to find another terminal and kill yourself, you just unplug the rs232 from your terminal and when you plug it back in you have been logged out and have a new getty process. You have to admit that the delay is annoying, and that wiring the terminal correctly solves the problem. My sympathies to those of you whose terminals are wired wrong. Jim Rees Jim@Washington ...!ucbvax!lbl-unix!uw-beaver!jim ...!decvax!microsoft!uw-beaver!jim -------
pat (09/20/82)
#R:sri-unix:-327500:uicsovax:5500026:000:287 uicsovax!pat Sep 18 09:32:00 1982 We have found that the sleep/flush is needed to get rid of the garbage that gets reflected from long unterminated tty lines (lines with terminal disconnected for repair or switched to differrent machine). That sleep(1) could probably be replaced by the "nap" system call. Pat Kane