Xref: utzoo comp.lang.c:18900 comp.unix.questions:13808
Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: sccs troubles
Keywords: ndir sccs access errors
Message-ID: <1689@auspex.auspex.com>
Date: 23 May 89 18:20:23 GMT
References: <784@jonlab.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Followup-To: comp.unix.questions
Organization: Auspex Systems, Santa Clara
Lines: 33

>Within the "clean" function of "sccs", the line:
>
>	dirp = opendir(buf);
>
>is reached.  Buf is "SCCS" and opendir returns a valid (non-zero)
>pointer.  However, in the subsequent loop checking file names, "x.c",
>"y.c", and "SCCS" are found rather than "p.y.c", "s.x.c", and "s.y.c".
>Thus, no "p.XXX" files are found.
>
>The environment is SVR3.0 on an AT&T 3B2 and version 3.51 of the O.S.
>on an AT&T UNIX-PC.  Directory access routines come from the "ndir"
>package that was published on the net.

Beats me.  Maybe the "ndir" package doesn't work right on your systems?
When using S5R3.0, there's no need to use it; it comes with S5R3. 
"sccs", as it comes from Berkeley, is set up to use the 4.xBSD version
of the package, rather than the POSIX/S5R3 version; to change it to use
the POSIX/S5R3/4.4BSD? version, just:

	1) change the "# include <sys/dir.h>" to "# include <dirent.h>;

	2) change "struct direct" to "struct dirent".

(I presume you've already caught uses of "index" and "rindex" and, if
necessary, used "strchr" and "strrchr" instead.)

You're absolutely sure "buf" is "SCCS" - i.e., you've checked it with a
"printf" or with a debugger like "sdb", right, not just assumed that it
had to be "SCCS" given the path it took to get there?  It might be that
it's somehow been compiled so that it thinks SCCS files are in the
current directory, rather than in an SCCS subdirectory.  (Note, BTW, that
that may, in fact, be the right way to build it for vanilla S5 systems -
S5's "make" doesn't know about SCCS subdirectories, by default.)