I did not rewrite the header files or man pages since they are the same as
Sun's so you will need to have them.

Below is the README file that goes along with the routines.


                    Glenn Mackintosh
                    Univ. of Toronto

CSNET/ARPA:   glenn@eecg.{toronto.edu,utoronto.ca}
CDNNET:       glenn@eecg.toronto.cdn
BITNET:       glenn@eecg.utoronto.bitnet (may not work from all sites)
UUCP:         uunet!utai!eecg!glenn



    The purpose of these routines is to allow those of us that don't really
like Suns yellow pages implimentation to get some of the benifits of yp
without actually having to run them. For example you can use netgroup
entries in your /etc/exports and in your .rhosts files. For those lost souls
who actually do run yp you can selectively recompile some programs like
finger (speeds it up by an order of magnitude (decimal) at least) and shells
(speeds up ~person expansion about the same as it speeds up finger, also
gets rid of the problem with losing the socket connection to the yp server
when you try and do a mispelled file expansion).

    The routines in this library emulate the Sun yellow pages routines. They
do not use RPC to talk to a server though. The routines assume that the
database files are in a publicly accessible place; either nfs mounted,
track'ed, rdist'ed, ... (be careful with track and rdist with the dbm files
since they fill in the holes in the dbm files so they will take up more
space, it isn't to critical but the resulting file will be maybe twice as
large). The location of these files is specified in the yp.h file or can be
overridden at compile time by defining DBMFILEPATH for the compiler
(something like -DDBMFILEPATH=\"/etc/yp/\"). 

    The other change is that the routines which access the database in a
sequential manner, yp_all and yp_first/next, do not use the dbm routines.
Instead they open the file themselves and walk through it a line at a time.
This speeds up things like finger and the shells ~ expansion by an order of
magnitude. This means however that a copy of the original file from which
the dbm databases were generated also needs to live in the directory along
with the .pag and .dir files. The yp_all routine opens the file
independently of the yp_first/next routines so that they don't interact.
All the other routines (yp_match, etc.) do use the dbm databases since the
hashed lookups are much faster when random access is really what you're
doing.

    These routines can handle data for multiple domains. It uses a separate
directory for each domain and tacks the domain on when it tries to locate
the file. For example if you wanted to look at host.byname info for domain
csri; it would look in /etc/yp/csri/host.byname{,.dir,.pag}.

    The library routines being used should be identical as far as interface
is concerned to the sun yp routines so I have not provided man pages, just
look at Suns man pages. You will have to keep the dbm databases up to date
and generate the reversed maps (*.byuid and *.byaddr) files just as you would
have to if you were running yp.

    In Sun's version of yp_next they need to pass the last key to the yp
server since it is stateless. We are just opening the file and walking
through which is statefull. This results in a potential problem though since
it means that in Suns yp you could hand it arbitrary keys and get the next
one.  To do this here would be unpleasant but not difficult. However, by
definition the order of the entries in the maps is arbitrary as far as the
user is concerned (wherever the hashing places them) so to hop about in this
manner makes no sense. I therefore decided to consider any code that does
this to be broken and don't support this feature. If someone comes up with a
reasonable argument to the contrary I might change this.

    There is a small problem with linking in these routines to programs that
don't call the yp routines directly but call routines like getpwent that
call the yp routines. Since they are not undefined when the linker goes
through the file it will not include them. Then when it gets to the getpwent
routine in libc it will look there and find the system ones which is not
what you intended. To get around this I have also included a yp_linkfake.o
which is basically a stub that is never called but has calls in it to all
the fake yp routines. If you link with this then it should work fine. Here
is an example of a piece of a Makefile that does this:

CFLAGS=-g
NAME=finger
YPDIR=/a/glenn/hack/yp

all: $(NAME)
$(NAME): $(NAME).c
	cc $(CFLAGS) $(NAME).c -o $(NAME) $(YPDIR)/yp_linkfake.o \
		-L$(YPDIR) -lyp



Let me know if you find any problems.

                    Glenn Mackintosh
                    Univ. of Toronto

CSNET/ARPA:   glenn@eecg.{toronto.edu,utoronto.ca}
CDNNET:       glenn@eecg.toronto.cdn
BITNET:       glenn@eecg.utoronto.bitnet (may not work from all sites)
UUCP:         uunet!utai!eecg!glenn