Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!occrsh!occrsh.ATT.COM!rjd From: rjd@occrsh.ATT.COM.UUCP Newsgroups: comp.unix.wizards Subject: Re: login prompt not staying set Message-ID: <142700015@occrsh.ATT.COM> Date: Sun, 6-Dec-87 11:39:00 EST Article-I.D.: occrsh.142700015 Posted: Sun Dec 6 11:39:00 1987 Date-Received: Sat, 12-Dec-87 09:26:36 EST References: <142700001@occrsh.ATT.COM> Lines: 36 Nf-ID: #R:occrsh.ATT.COM:142700001:occrsh.ATT.COM:142700015:000:1913 Nf-From: occrsh.ATT.COM!rjd Dec 6 10:39:00 1987 > >Believe me, Im a novice at this. But it occurred to me . . . > >Does it make sense for login, after an invalid password, to exec getty > >... > > ........ > So, remember that it is "getty" which asks for ``login:'' and not the prog > login itself; that's the reason why a passwd can't be typed in before being > prompted for it on the Unix. Uuuummm, go re-read my artical (the base note) again. Login(1) DOES prompt for the login id if: 1) the login id is invalid (after prompting for the password anyway), or 2) the password entered to a valid login was incorrect. And no, that is NOT the reason the password cannot be entered before it is prompted. The reason you must wait for the prompt is that the "gpass" routine is used to prompt for the password, which, directly prior to printing the prompt (and setting echo to off), a fflush(stdin) is performed (which zeros out the input queue so no characters, no matter how many WERE there, are waiting to be read). If the fflush was not performed, the characters typed before the password prompt would still be in the input stream and thus still be available, no matter which program tried to read the input stream. This was implemented, I assume, to prevent users from getting in the habit of typing the password while it would be visible (echo still on) and force the user to wait for the echo to be set off before it would accept the password. The idea to exec getty again would involve telling login(1) which options the original getty was invoked with. It would be much easier to tell login to exit after printing "login incorrect" (and letting init re-start the getty), but then you run into the problem of the last closed process hanging up the line (if hupcl is set, which you DO normally want done) which would screw up anyone coming in through a properly set up modem (it would, of course, not affect hardwired terminals). Randy