install-log-devel — install-log developers' list

[ID] timestamp.c

[Andy G. <unu...@op...>]

... has been added.  Play with it some.

Hey, do you want to convert find_newer to use the linked list exclude, or do 
you want me to show you how (i.e. do it for you)?  And do you want me to fix 
the tab stops?  I don't want to mess with logger.c--it's your file--without 
your permission.  I mean, stomping on your work isn't productive!

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

[ID] realpath

[Andy G. <unu...@op...>]

Found it!!

$ man realpath

REALPATH(3)         Linux Programmer's Manual         REALPATH(3)
 
NAME
       realpath - return the canonicalized absolute pathname
 
SYNOPSIS
       #include <limits.h>
       #include <stdlib.h>
 
       char *realpath(const char *path, char *resolved_path);

...

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] Linked lists

[Andy G. <unu...@op...>]

(Damn, I did it again.)

> logger.c... would you mind sticking to 80 columns?  That's pretty much
> standard.

Maybe you *are* using 80 columns, but we have different tab stops.  I try to 
stick to the Linux kernel source indentation and layout, so that means a tab 
stop every eight characters.  That forces me to avoid nesting too deeply.  (I 
still need to work on that one, though.)

> I'll read through and compile logger.c in a moment.  Thanks for writing it!

logger.c compiles just fine, here, but it never gets called.

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] Linked lists

[Andy G. <unu...@op...>]

Gawrsh, I am creating soooo much traffic here!  Immediately after sending an 
email, something changes that I wish I could have written about prior.

So, the big change now is that I managed to log in to cvs again and summarily 
was able to commit my changes and download logger.c.

logger.c... would you mind sticking to 80 columns?  That's pretty much 
standard.

I'll read through and compile logger.c in a moment.  Thanks for writing it!

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] Linked lists

[Andy G. <unu...@op...>]

> Done.  It also initializes the char*'s.  The current system had memory
> leaks, but now they appear to be patched.

Current?  I meant the OLD system.  Whoops...

Can you think of any better ways of keeping track of these configuration 
variables than globals?  I'd use something else if I could get away from it.  
Maybe they can be extracted from the configuration data array, but that would 
mostly just add more indirection, and God knows I have too much of that 
already!

Okay, maybe you can make changes before I do my patch, but before cvs commit, 
do cvs update.  Then if cvs can't merge your changes, the version you had 
before you made changes (on the server), and the latest version on the 
server, it'll put these huge <<<<<<< and >>>>>>>> thingies in the file to 
show you where to fix up the problems.

I forgot to do cvs update... <hangs head in shame>.  Sorry.  I haven't ever 
written to a cvs-based project with more than one active member.  (See 
mage-oop; the other guy hasn't coded a line--doesn't really know how, I 
guess.)

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] Linked lists

[Andy G. <unu...@op...>]

On Tuesday, July 24, 2001 5:21, Andy Goth wrote:
> I just added list.c and list.h.  Check them out.  They're not comprehensive
> or anything.  I haven't even tested them, but they do compile properly.

Okay, now I fleshed things out and made the rest of the program use linked 
lists.

I also accidentally stomped on your changes to module.mk and install-log.h.  
I am now trying to fix it, but the cvs server seems to be momentarily down.

$ cvs commit -m "re-added jreeves's changes that I accidentally stomped on"
usw-pr-cvs.sourceforge.net: Connection refused
cvs [commit aborted]: end of file from server (consult above messages if any)

So be careful.  Let me submit this patch before you do anything else.  Then 
be sure to do cvs update before writing any more code.  I should do the same 
to get logger.c.

> I'm about to add a function to generate a linked list of strings given a
> char** to a NULL-terminated array.

Done.

> Then I'll make some sort of
> set_global_variables_to_default_values_before_reading_the_user_configuratio
>n function that can make use of it.

Done.  It also initializes the char*'s.  The current system had memory leaks, 
but now they appear to be patched.

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

[ID] Linked lists

[Andy G. <unu...@op...>]

I just added list.c and list.h.  Check them out.  They're not comprehensive 
or anything.  I haven't even tested them, but they do compile properly.

I'm about to add a function to generate a linked list of strings given a 
char** to a NULL-terminated array.  Then I'll make some sort of 
set_global_variables_to_default_values_before_reading_the_user_configuration 
function that can make use of it.

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] Reply-To?

[Andy G. <unu...@op...>]

> On my client I use "list reply" to reply via the list, although looking
> through the headers this doesn't generate a reply-to pointing back to the
> list - if you want I can try and get it to do so.

I have a similar feature, but I didn't realize it until just now.

> As for the reply-to for the mailing list, I can't see it would do any harm
> to add the reply-to; looking at some other lists I'm subscribed to they
> seem to do it automatically. And if anyone complains it can always be taken
> down :)

It's actually a bad idea to mess with reply-to, so I'll avoid it if I can.

Forget I brought it up.

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] logger (find_newer)

[James R. <jr...@fu...>]

On Tue, Jul 24, 2001 at 04:55:26PM -0500, Andy Goth wrote:
> > > Hey, I think I'll recode the exclude list as a linked list.  Is that
> > > okay?  I need to fix one of the memory leaks I mentioned in config.c.
> >
> > Ok, but I'll need to change the checking for excluded dirs bit from a for
> > loop to a while != NULL :)
> 
> Or use the proc_list function I just wrote...

ok, that's easier :)

> > > I don't care what state your file is in.  Please add and commit it now so
> > > that we can work on it together.
> >
> > Sorry, took me a while to get cvs all up and working properly. It's up now,
> > though the find_newer function isn't attached to anything as of yet. I did
> > a release on the version of code I used to test it as it was very messy, so
> > find_newer isn't called in the main program.
> 
> Any ideas for what source file it should go in?

Well, as it's going to just write to a linked list and so doesn't need to be
called by a specific function, I would be tempted to add it in main.

> > > Since we'll have so many linked lists, I'll need to create a list.c file
> > > for managing them.  There'll be a function to, for example, call the
> > > given function on each element.  Would that help?  Or is it overkill,
> > > because linked lists can be traversed easily enough in a for statement?
> >
> > You could set up a generic struct for linked lists:
> >
> > struct llist {
> > 	void* data;
> > 	struct llist* next;
> > };
> >
> > As that would standardise them a bit. It might be worth writing a "search
> > linked list function though, as that'll be needed for both include and
> > exclude lists.
> 
> Oh, right, searching.  Maybe there could be a function to convert an include 
> or exclude list into a (temporary) binary tree, for efficient searching.  
> How's that?

The question is whether coverting to a binary tree then searching is faster
then a normal search, taking into account that there's only going to be a few
entries and under 300 tests (assuming less than 300 dirs in /usr, /bin etc.)? I
think this is one of those problems where the "right" answer isn't that clear
:)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] Reply-To?

[James R. <jr...@fu...>]

On Tue, Jul 24, 2001 at 03:53:53PM -0500, Andy Goth wrote:
> Should I have the mailing list set reply-to to point to the list, or should I 
> leave it as-is?  I have set up my mail client to automatically set my own 
> reply-to, but I don't want to stomp on the toes of any other subscribers by 
> forcing the reply-to issue.  What do you think?

On my client I use "list reply" to reply via the list, although looking through
the headers this doesn't generate a reply-to pointing back to the list - if you
want I can try and get it to do so.

As for the reply-to for the mailing list, I can't see it would do any harm to
add the reply-to; looking at some other lists I'm subscribed to they seem to do
it automatically. And if anyone complains it can always be taken down :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] logger (find_newer)

[Andy G. <unu...@op...>]

(Crud, did it again!  I need to use Reply All to make this work.)

On Tuesday, July 24, 2001 4:52, you wrote:
> On Tue, Jul 24, 2001 at 03:47:56PM -0500, Andy Goth wrote:
> > Hey, I think I'll recode the exclude list as a linked list.  Is that
> > okay?  I need to fix one of the memory leaks I mentioned in config.c.
>
> Ok, but I'll need to change the checking for excluded dirs bit from a for
> loop to a while != NULL :)

Or use the proc_list function I just wrote...

> > I don't care what state your file is in.  Please add and commit it now so
> > that we can work on it together.
>
> Sorry, took me a while to get cvs all up and working properly. It's up now,
> though the find_newer function isn't attached to anything as of yet. I did
> a release on the version of code I used to test it as it was very messy, so
> find_newer isn't called in the main program.

Any ideas for what source file it should go in?

> > Since we'll have so many linked lists, I'll need to create a list.c file
> > for managing them.  There'll be a function to, for example, call the
> > given function on each element.  Would that help?  Or is it overkill,
> > because linked lists can be traversed easily enough in a for statement?
>
> You could set up a generic struct for linked lists:
>
> struct llist {
> 	void* data;
> 	struct llist* next;
> };
>
> As that would standardise them a bit. It might be worth writing a "search
> linked list function though, as that'll be needed for both include and
> exclude lists.

Oh, right, searching.  Maybe there could be a function to convert an include 
or exclude list into a (temporary) binary tree, for efficient searching.  
How's that?

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] logger (find_newer)

[James R. <jr...@fu...>]

On Tue, Jul 24, 2001 at 03:47:56PM -0500, Andy Goth wrote:
> Hey, I think I'll recode the exclude list as a linked list.  Is that okay?  I 
> need to fix one of the memory leaks I mentioned in config.c.

Ok, but I'll need to change the checking for excluded dirs bit from a for loop
to a while != NULL :)

> I don't care what state your file is in.  Please add and commit it now so 
> that we can work on it together.

Sorry, took me a while to get cvs all up and working properly. It's up now,
though the find_newer function isn't attached to anything as of yet. I did a
release on the version of code I used to test it as it was very messy, so
find_newer isn't called in the main program.
 
> > At the moment it assumes that only directories can be excluded, as it is
> > fairly easy to do so;
> 
> What else would be excluded?  Individual files?  I can't think of a single 
> case for including them.
> 
> Hmm... including...
> 
> Maybe we should have an optional include list as well, which will default to 
> simply "/".  It'll start scanning from every entry listed in it.  It might be 
> easier to say --include="/bin:/lib:/opt:/sbin:/usr" than 
> --exclude-"/boot:/dev:/etc:/home:/mnt:/music:/proc:/root:/src:/tmp:/var".

Sounds like a good idea.
 
> Since we'll have so many linked lists, I'll need to create a list.c file for 
> managing them.  There'll be a function to, for example, call the given 
> function on each element.  Would that help?  Or is it overkill, because 
> linked lists can be traversed easily enough in a for statement?

You could set up a generic struct for linked lists:

struct llist {
	void* data;
	struct llist* next;
};

As that would standardise them a bit. It might be worth writing a "search
linked list function though, as that'll be needed for both include and exclude
lists. Still, it would only be 4 lines or so even then. Probably not worth it
then, at least for the moment. We can always add the functions in later if we
find it's getting a bit too complicated.

> > With files, it's a tad more difficult
> > as:
> >
> > 1. More entries will have to be checked.
> > 2. The entry "flub" in "/usr/local/bin" should match "/usr/local/bin/flub"
> > (and "/usr/local/bin/flub/") - more than a simple strcmp.
> > 3. The root dir is different in that it ends with a '/', while sublevel
> > dirs don't.
> 
> Just strip trailing /'s and all duplicated /'s ("/usr//local/" --> 
> "/usr/local").  I think there's actually a function for that sort of thing.  
> Oh, wait, that was only with djgpp.

Easy enough to write:

char* p;
char* q;
for (p = filename; *p != 0; p++) {
	if ( (*p == '/') && ( (*(p+1) == '/') || (*(p+1) == 0) ) ) {
		for (q = p; *q != 0; q++)
			*q = *(q+1);
	}
}

That'll probably work :)

> > No big deal, but may slow the code down a bit. What do you think?
> 
> I don't think there's a reason for working with individual files in this way.

Ok. Makes my job easier :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

[ID] Reply-To?

[Andy G. <unu...@op...>]

Should I have the mailing list set reply-to to point to the list, or should I 
leave it as-is?  I have set up my mail client to automatically set my own 
reply-to, but I don't want to stomp on the toes of any other subscribers by 
forcing the reply-to issue.  What do you think?

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] logger (find_newer)

[Andy G. <unu...@op...>]

On Tuesday, July 24, 2001 9:29, you wrote:
> On Mon, Jul 23, 2001 at 06:28:29PM -0500, Andy Goth wrote:
> > (oops, once again didn't send to ID)
>
> And you complain about me forgetting attachments, tsk tsk :)

That's weird.  Maybe SourceForge turned off the reply-to feature of mailman.  
I'll go check.

> > > Oops! My mistake. I'm a bit new to this CVS thing :) - just let me
> > > install the latest ssh and I'll add it. Actually, I might as well make
> > > the changes to it before uploading it.
> >
> > It's okay to upload code that isn't quite perfect!  That way we can see
> > what each other is *doing*, not just what each other has *done*.
>
> Ok :) - I also need to ask your opinion on how to handle the exclude list.

Hey, I think I'll recode the exclude list as a linked list.  Is that okay?  I 
need to fix one of the memory leaks I mentioned in config.c.

I don't care what state your file is in.  Please add and commit it now so 
that we can work on it together.

By the way, if communication via email isn't enough, we can use cvs edit to 
declare which files we are currently working on.  Use cvs unedit to *cancel* 
editing (that means reverting).  I suppose cvs release is the right way to 
say that you're done editing.  Use cvs watch to keep an eye on the progress 
of a file.

Type cvs help to get a handy list.  (Actually, cvs blumfrub works too, as 
does any other nonrecognized command.)

> At the moment it assumes that only directories can be excluded, as it is
> fairly easy to do so;

What else would be excluded?  Individual files?  I can't think of a single 
case for including them.

Hmm... including...

Maybe we should have an optional include list as well, which will default to 
simply "/".  It'll start scanning from every entry listed in it.  It might be 
easier to say --include="/bin:/lib:/opt:/sbin:/usr" than 
--exclude-"/boot:/dev:/etc:/home:/mnt:/music:/proc:/root:/src:/tmp:/var".

Since we'll have so many linked lists, I'll need to create a list.c file for 
managing them.  There'll be a function to, for example, call the given 
function on each element.  Would that help?  Or is it overkill, because 
linked lists can be traversed easily enough in a for statement?

> checking if the working directory in each recursion
> matches if with any excluded entries.

In install-log.sh (that's what we'll call the old version, okay?), I just 
created a regular expression which, when matched, would cause find to stop 
with that entry and go on to the next one (without descending into matched 
directories).
"find . -regex ${PRUNE_REGEXP} -prune ..."

I suppose that with install-log.sh, individual files could be excluded, but 
that was not a design decision for me or Gerard or anybody else or that other 
guy who showed me how to use timestamps.

> With files, it's a tad more difficult
> as:
>
> 1. More entries will have to be checked.
> 2. The entry "flub" in "/usr/local/bin" should match "/usr/local/bin/flub"
> (and "/usr/local/bin/flub/") - more than a simple strcmp.
> 3. The root dir is different in that it ends with a '/', while sublevel
> dirs don't.

Just strip trailing /'s and all duplicated /'s ("/usr//local/" --> 
"/usr/local").  I think there's actually a function for that sort of thing.  
Oh, wait, that was only with djgpp.

> No big deal, but may slow the code down a bit. What do you think?

I don't think there's a reason for working with individual files in this way.

> Btw there also needs to be a check in the exclude list for an ending "/" in
> all but the root directory, probably when parsing the exclude dirs from the
> rcfile and the command line, so that "/dev/" == "/dev".

Sure, we'll get to that.

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] logger (find_newer)

[James R. <jr...@fu...>]

On Mon, Jul 23, 2001 at 06:28:29PM -0500, Andy Goth wrote:
> (oops, once again didn't send to ID)

And you complain about me forgetting attachments, tsk tsk :)
 
> > Oops! My mistake. I'm a bit new to this CVS thing :) - just let me install
> > the latest ssh and I'll add it. Actually, I might as well make the changes
> > to it before uploading it.
> 
> It's okay to upload code that isn't quite perfect!  That way we can see what 
> each other is *doing*, not just what each other has *done*.

Ok :) - I also need to ask your opinion on how to handle the exclude list. At
the moment it assumes that only directories can be excluded, as it is fairly
easy to do so; checking if the working directory in each recursion matches if
with any excluded entries. With files, it's a tad more difficult as:

1. More entries will have to be checked.
2. The entry "flub" in "/usr/local/bin" should match "/usr/local/bin/flub" (and
"/usr/local/bin/flub/") - more than a simple strcmp.
3. The root dir is different in that it ends with a '/', while sublevel dirs
don't.

No big deal, but may slow the code down a bit. What do you think?

Btw there also needs to be a check in the exclude list for an ending "/" in all
but the root directory, probably when parsing the exclude dirs from the rcfile
and the command line, so that "/dev/" == "/dev".

> > Perhaps a linked list would be the best way to do it? After all, if the
> > list is accessed, it will most likely be needed to go through the whole
> > thing, and the amount of files that each package installs can vary
> > considerably (like zlib compared to kde-base, zlib: 6, kdebase: 2489). An
> > array may be too inflexible in this case.
> 
> It might not be too bad if the array grows in hunks of 128 elements.  But 
> linked lists are easy enough to handle, so why not?

Ok, that's sorted then.

-- 
James Reeves (Shade)
http://arevol.envy.nu/

[ID] Makefile

[Andy G. <unu...@op...>]

To add a source file to the project, insert it into module.mk.  To add a 
module to the project, make a subdirectory for it, put a module.mk in the 
subdirectory, and add the subdirectory to project.mk.

depend.sh generates .d files for each .c.  The .d files list (what else?) the 
dependencies.  When changing around header files 'n junk, first delete the .d 
files, or make will choke.  The .d files can be quickly regenerated, so don't 
worry.  And don't upload them to cvs!

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] logger (find_newer)

[Andy G. <unu...@op...>]

(oops, once again didn't send to ID)

> Oops! My mistake. I'm a bit new to this CVS thing :) - just let me install
> the latest ssh and I'll add it. Actually, I might as well make the changes
> to it before uploading it.

It's okay to upload code that isn't quite perfect!  That way we can see what 
each other is *doing*, not just what each other has *done*.

> > It could be a combination, but I'm not sure yet.  For now, just have it
> > call a function for each file which adds it to an array.
> >
> > Now, this array poses a problem.  Every element should be a pointer to a
> > character array, right?  (char*)  Or should we make a more detailed
> > struct? Also, should this array be a linear vector (e.g., int
> > linear_vector[25]) that is sized to MAX_FILES (some predefined constant)
> > or can grow at runtime?  Or should this array actually be a linked list? 
> > Or should it be some other kind of data storage thingie?
>
> Perhaps a linked list would be the best way to do it? After all, if the
> list is accessed, it will most likely be needed to go through the whole
> thing, and the amount of files that each package installs can vary
> considerably (like zlib compared to kde-base, zlib: 6, kdebase: 2489). An
> array may be too inflexible in this case.

It might not be too bad if the array grows in hunks of 128 elements.  But 
linked lists are easy enough to handle, so why not?

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

Re: [ID] logger (find_newer)

[James R. <jr...@fu...>]

On Mon, Jul 23, 2001 at 04:14:46PM -0500, Andy Goth wrote:
> > Hi
> >
> > I've coded the first bit of logger.c, which cvs seems to be reluctant to
> > add - could you check if I've got write-access?
> 
> Remember that the pserver/anonymous thing only gives read-only.  To get 
> read-write, use:

Oops! My mistake. I'm a bit new to this CVS thing :) - just let me install the
latest ssh and I'll add it. Actually, I might as well make the changes to it
before uploading it.
 
> > I've attached logger.c to this email anyway,
> 
> Liar.

Ok, you got me there too - forgot to attach it so I put it in a separate email
:)

> > Also, find_newer() just prints out the files found at the moment. Do you
> > think it would be best to add all the files found to an array, or to deal
> > with each file at a time by calling a function once it's found to decide
> > where to put it? The latter option may be better because it'll take less
> > memory but there may be problems I haven't thought of :)
> 
> It could be a combination, but I'm not sure yet.  For now, just have it call 
> a function for each file which adds it to an array.
> 
> Now, this array poses a problem.  Every element should be a pointer to a 
> character array, right?  (char*)  Or should we make a more detailed struct?  
> Also, should this array be a linear vector (e.g., int linear_vector[25]) that 
> is sized to MAX_FILES (some predefined constant) or can grow at runtime?  Or 
> should this array actually be a linked list?  Or should it be some other kind 
> of data storage thingie?

Perhaps a linked list would be the best way to do it? After all, if the list is
accessed, it will most likely be needed to go through the whole thing, and the
amount of files that each package installs can vary considerably (like zlib
compared to kde-base, zlib: 6, kdebase: 2489). An array may be too inflexible
in this case.

Now to bed - it's 11pm here *yawn*

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] logger (find_newer)

[Andy G. <unu...@op...>]

(resending to the mailing list--I guess I need to set an explicit reply-to 
header for mailing list items)

On Monday, July 23, 2001 3:03, you wrote:
> Hi
>
> I've coded the first bit of logger.c, which cvs seems to be reluctant to
> add - could you check if I've got write-access?

Remember that the pserver/anonymous thing only gives read-only.  To get 
read-write, use:

export CVSROOT=":ext:jr...@cv...:/cvsroot/install-log"
export CVS_RSH="ssh"
cvs login # Only once

To add logger.c, use:

cd ${DEVEL-ROOT}/install-log
cvs add logger.c
cvs commit -m"began work on file creation/modification detection"

> I've attached logger.c to this email anyway,

Liar.

> and works quite well, although I need to neaten it up
> somewhat and some bits need fiddling around with.

I'll play with it, but not until you put it in the cvs!

> Also, find_newer() just prints out the files found at the moment. Do you
> think it would be best to add all the files found to an array, or to deal
> with each file at a time by calling a function once it's found to decide
> where to put it? The latter option may be better because it'll take less
> memory but there may be problems I haven't thought of :)

It could be a combination, but I'm not sure yet.  For now, just have it call 
a function for each file which adds it to an array.

Now, this array poses a problem.  Every element should be a pointer to a 
character array, right?  (char*)  Or should we make a more detailed struct?  
Also, should this array be a linear vector (e.g., int linear_vector[25]) that 
is sized to MAX_FILES (some predefined constant) or can grow at runtime?  Or 
should this array actually be a linked list?  Or should it be some other kind 
of data storage thingie?

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

[ID] Oops - forgot logger.c

[James R. <jr...@fu...>]

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <dirent.h>
#include <errno.h>
#include <string.h>

#include "install-log.h"

char cwd[PATH_MAX];										/* current working directory */

int find_newer(const char* dirname, const time_t timestamp)
{
	DIR* pdir;												/* pointer to directory */
	struct stat buf;										/* buffer for filename stats */
	struct dirent* d = NULL;							/* current directory entry */
	char** ex_p;
	
	if (chdir(dirname) == -1)
		return 0;											/* XXX check for specific errs? */
	
	getcwd(cwd, PATH_MAX);								/* get working directory */

	for (ex_p = exclude; *ex_p != NULL; ex_p++) {	/* search exclude list */
		if (strcmp(cwd, *ex_p) == 0)
			return 1;										/* return if cwd excluded */
	}

	pdir = opendir(".");

	while (d = readdir(pdir))
	{
		/* if not '.' or '..' */
		if ( (strcmp(d->d_name, ".") != 0) && (strcmp(d->d_name, "..") != 0) )
		{
			if (lstat(d->d_name, &buf) == -1) {		/* get info on directory entry */
				perror("stat");							/* report any errors */
				continue;									/* carry on - should be ok */
			}

			if (S_ISDIR(buf.st_mode)) {				/* if current entry is a directory */
				if (find_newer(d->d_name, timestamp))	/* work on that directory */
					chdir("..");								/* change back out of directory */
				getcwd(cwd, PATH_MAX);					/* get working directory */
			}
			else if (timestamp < buf.st_mtime) {	/* else if recently modified */
				printf("%s/%s\n", cwd, d->d_name);	/* XXX should output to file */
			}
		}
	}

	closedir(pdir);
	return 1;
}

[ID] logger (find_newer)

[James R. <jr...@fu...>]

Hi

I've coded the first bit of logger.c, which cvs seems to be reluctant to add
- could you check if I've got write-access? I've attached logger.c to this
email anyway, and works quite well, although I need to neaten it up somewhat
and some bits need fiddling around with. 

Also, find_newer() just prints out the files found at the moment. Do you think
it would be best to add all the files found to an array, or to deal with each
file at a time by calling a function once it's found to decide where to put it?
The latter option may be better because it'll take less memory but there may be
problems I haven't thought of :) 

-- 
James Reeves (Shade)
http://arevol.envy.nu/

[ID] Hello (2)

[Andy G. <unu...@op...>]

Welcome to the install-log-devel mailing list.

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html

[ID] Hello (1)

[Andy G. <unu...@op...>]

Welcome to the install-log-devel mailing list.

-- 
Andy Goth   |   unu...@op...
---------------------------------------
http://www.toad.com/gnu/whatswrong.html