Re: getpass.c

[Yves Pelletier <ypell@cam.org>]

On Fri, 20 Jun 1997, Howard Chu wrote:

>   Background: this loop is part of a routine that takes a string
>   from a tty, then strips the trailing end-of-line character.
>   I modified it to do the same thing if it encounters an EOF:
> 
> The typical Unix behavior is that an EOF character is only recognized
> if it is the first character in an input stream. If you type a bunch
> of characters in response to a prompt, and type an EOF, that will not
> terminate the input. So, you only need to check to see if the first
> character you read is an EOF. Otherwise, the input line *must* end
> with a newline.

This makes sense, but here is what I found a little while ago in
the SunOS getpass() manpage at my ISP's: 

 "getpass reads up to a newline or EOF from the file /dev/tty,
  after prompting on the standard error output with the 
  null-terminated string prompt and disabling echoing."

I later saw the IRIX and HPUX manpages; they are identical to
the above.

On the assumption that the standard login program calls getpass,
I experimented with three systems: my ISP's SunOS; and IRIX and
HPUX systems we have at work. 

The IRIX system behaved in the fashion you describe as typical,
but accepted my password even with an EOF before the newline.

SunOS refused to log me in if there was an EOF in the password
string.

Only HPUX behaved as advertised in the manpage (handling EOF the
same as \n).

Perhaps getpass needs to differ from standard Unix behaviour? 
For instance, imagine the password is fed from a file, through
some automated mechanism.  If the file contains
"mypassword<EOF>" instead of "mypassword\n<EOF>", getpass will
keep waiting for a newline that might never come.  For that
reason, I favour the HP-UX behaviour.  (Not to mention that it's
the only system that actually does what the manpage says. :-)

Yves