Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: login gripes
Message-ID: <16079@sun.uucp>
Date: Thu, 2-Apr-87 14:37:24 EST
Article-I.D.: sun.16079
Posted: Thu Apr  2 14:37:24 1987
Date-Received: Sat, 4-Apr-87 18:49:12 EST
References: <8703231450.AA18626@ephemeral.ai.toronto.edu> <15831@sun.uucp> <553@westpt.usma.edu>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 27
Summary: Sigh, another self-proclaimed "expert" who isn't

>Actually what is happening is the password is taken in using a call to
>the routine getpass() which reads directly from /dev/tty and not from
>the stdin. So anything you typed before getting the Password: prompt
>went to the stdin and is not available to that call.

Excuse me?  "/dev/tty" is just an indirect device that refers to a
process' controlling terminal.  That terminal is also the standard
input for "getty" and "login".  The explanation above is completely
bogus; anything you type before getting the Password:  prompt most
definitely *would* be available, were it not for the flush caused by
switching from RAW to non-RAW mode.

>The echo goes away because reading from /dev/tty has nothing to do
>with the current settings of stty.

You wanna bet?  Reading from "/dev/tty", since it's just an indirect
device referring to the controlling terminal, most definitely *does* have
something to do with the current mode settings on the controlling
terminal.  Try it!

>Another catch to this method is reads and writes to/from /dev/tty cannot
>be redirected.

That's one reason why "/dev/tty" is there!  Programs - such as
programs that read passwords - may want to guarantee that they'll
read from the process' controlling terminal even if their standard
input has been redirected away from that terminal.