From: utzoo!decvax!duke!harpo!floyd!trb Newsgroups: net.unix-wizards Title: getty.c Article-I.D.: floyd.486 Posted: Fri Aug 27 17:05:19 1982 Received: Mon Sep 6 01:15:54 1982 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-6491