Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: 'ls -n' opens password file for reading
Message-ID: <1646@auspex.auspex.com>
Date: 18 May 89 16:35:58 GMT
References: <1326@rivm05.UUCP> <128@softop.UUCP> <1622@auspex.auspex.com> <1245@aplcen.apl.jhu.edu> <638@cbnewsh.ATT.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 21

>Two possible improvements:
>	1) ls currently (svr3) remembers the last uid & gid
>	searched for an SUCCESFULLY found in the /etc/(passwd|group)
>	file.  This "buffer :)" should be enlarged and also include
>	unfound ids.

The SunOS S5 "ls" ("/usr/5bin/ls"), as I remember, has the same UID/GID
lookup cache as does the SunOS 4BSD "ls" ("/usr/bin/ls", or "/bin/ls" on
older versions), which is derived from the 4.xBSD version, and which
handles multiple UIDs and GIDs.  The BSD version doesn't handle missing
IDs, though; I don't remember whether the SunOS one does.

(Oh, and while you're doing this, fix it to use "getpwuid" and
"getgrgid", as mentioned in a previous article....)

>	2) This would elliviate the need for a larger buffer;
>	use some kind of database system to speed up access to
>	the password file (I belive some BSD systems may do this)

Yes, 4.3BSD uses an "ndbm" index to the password file in "getpw*"; since
their "ls" uses "getpwuid", it picks up the improvement automatically.