jon@jonlab.UUCP (Jon H. LaBadie) (05/23/89)
I've recently begun using the BSD program called sccs, to interface to the sccs system. I've run into a defect using the "info" command that requests which files are currently open for editing. "sccs" always reports "Nothing being edited"! I've tracked the problem down to the fact that sccs is reading the wrong directory. It is using the current directory rather than the designated SCCS directory. Here is the situation: SRC ______|__________ | | | x.c y.c SCCS _______|_______ | | | p.y.c s.x.c s.y.c 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. Any idea what gives?
guy@auspex.auspex.com (Guy Harris) (05/24/89)
>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.)
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/24/89)
In article <784@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >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. SVR3.0 supposedly came with its own dirent implementation, which you should use. <dirent.h> for the system-provided implementation is not necessarily compatible with dirent.h for the net-obtained library.
clewis@ecicrl.UUCP (Chris Lewis) (05/30/89)
In article <784@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes: >I've recently begun using the BSD program called sccs, to interface >to the sccs system. I've run into a defect using the "info" command >that requests which files are currently open for editing. "sccs" always >reports "Nothing being edited"! >I've tracked the problem down to the fact that sccs is reading the wrong >directory. It is using the current directory rather than the designated >SCCS directory. Here is the situation: [Further stuff on the bug.] This may or not be your problem depending on how "sccs" is written, but there is a bug (feature?!) in the version of ndir distributed with B-news. It will *not* work recursively. If you nest opendir (ye olde recursive directory scan algorithm), subsequent readdir's can be somewhat confusing. The reason is that, while "opendir" does malloc and return a new structure on each invocation, there is no attempt to malloc a new area for readdir to return - there's precisely one statically allocated buffer. So: dirp1 = opendir("foo"); dirp2 = opendir("foo2"); d1 = readdir(dirp1); d2 = readdir(dirp2); The d1 and d2 pointers point at the same place.... I have a version of ndir that has *this* particular bug fixed in the unlikely event that anybody needs it. I didn't bother retrofitting the fix into News because it doesn't matter to news - I was using these routines for another program... -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)