In article <199510230305.NAA12894@balrog.supp.cpr.itg.telecom.com.au>,
Simon Burge  <simonb@telstra.com.au> wrote:
> There's the way (I think) that  Ultrix does it.  Basically,  "passwd-0"
> is a CNAME for the first password entry, "passwd-1" for the next, and
> so on.  getpwent() just cycles through, until you don't get an answer
> for "passwd-N".  A little ugly, but it works ok.

Hey, now that's the best idea I've seen yet! If someone wants getpwent
to work, it's trivial to write a script to generate the passwd-N entries
automatically. If someone doesn't want it (maybe they have 100K users and
don't want their network swamped with tilde-completeion traffic),
just don't add those entries to the hesiod server. Hesiod getpwent()
could be made to deal with this elegantly by falling back to the local
password file (or the next service in nsswitch, or whatever) if passwd-0
is not present on the first getpwent() attempt.

Advantages:
	hespwent() code size would be small
	hespwent() would have very low memory requirements
	hespwent() still implements the full semantics of getpwent()
		if the server is set up for it
	hespwent() can still work reasonably if the server isn't
		set up for it
	compatible with existing practice

I don't even think it's that ugly... it fits with how hespwuid() works.