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