On Wed, 17 Jul 1996, der Mouse wrote:

> > I'm curious as to why setpwfile() was deprecated.
> 
> In both cases (NetBSD and Sun) I think it's stupid.  It's just too
> useful to be able to work on alternative databases, and deprecating it
> really doesn't buy anything. 

What should the format of the alternative database be that you specify
with setpwfile()?  There are at least three in NetBSD: 

	/etc/{s,}pwd.db - hashed db, what libc reads
	/etc/master.passwd - the 10-field flat text file that pwd_mkdb reads
	/etc/passwd - the V7 flat text file, for compatibility

Most programs that call setpwfile() probably will be wanting to parse V7
passwd files.  But NetBSD doesn't even contain code to parse those
anymore.  The problem is that setpwfile() forces the data to be stored in
a set format, when this really shouldn't be the case.

Where I work, some local source depended on setpwfile(), so I wrote a
trivial set of functions that access "uid tables" (which is we call V7
passwd files around here): 

int setutabfile __P((char *));
int setutabent __P((void));
int endutabent __P((void));
struct passwd *getutabent __P((void));
struct passwd *getutabnam __P((char *));

Then I just changed all occurances of setpwfile() and subsequent
getpwnam()'s etc to setutabfile() and getutabnam().  IMO, this is how
programs that use setpwfile() should be handled.

mike