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

Re: [ID] Man Page

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

> No need; just stick it in the $PREFIX/man/man1 dir. You can look at it with
> "man ./install-log.1". Manedit is nice in this respect as it automatically
> converts to proper man format when saved.

Oh, that's so cool.

> > 1.9 needs some polishing, that's it.  Stuff like the --quiet feature and
> > better management of strings.
>
> Isn't it already quiet w/o verbose on?

Yes, but it's not supposed to be.  When it comes across deleted and/or old 
files, it should print a list to screen.  I'll get to that soon.  _Then_ 
quiet'll have a meaning!

...

Back to debugging.  I'm modifying a bunch of junk to use safe_sprintf and 
friends, but I've made a couple boo-boos I'm busily sniffing out.

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

Re: [ID] Man Page

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

On Sun, Jul 29, 2001 at 01:45:07PM -0500, Andy Goth wrote:
> On Sunday, July 29, 2001 7:39, James Reeves wrote:
> > I've started work on the man page btw, just so that we don't duplicate each
> > others work.
> 
> Oh, wow.  Thanks.  Could you give me information on how to compile it so that 
> I can put it in the Makefile?

No need; just stick it in the $PREFIX/man/man1 dir. You can look at it with
"man ./install-log.1". Manedit is nice in this respect as it automatically
converts to proper man format when saved.
 
> > We also need to figure out who needs to work on what; at the moment I seem
> > to be just tidying up things generally, although to be fair I suppose we've
> > got most of the features for v2.0 in already :)
> 
> We do?  You'd better hurry up and cvs commit them!!  <g>

I meant 1.9 :) - I just thought "stable version" and so put down 2.0

> 1.9 needs some polishing, that's it.  Stuff like the --quiet feature and 
> better management of strings.

Isn't it already quiet w/o verbose on?

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

[ID] proc_list_xxx

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

I replaced proc_list_parm with proc_list_va.  I haven't tested it yet, 
because I'm busy with the string functions, which by the way I have fixed and 
made a demo for.  cvs update to get it.  We'll remove the demo soon, when we 
see that everything works properly and agree on the syntax and junk.

Okay, back to fprintf_list...

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

Re: [ID] Man Page

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

On Sunday, July 29, 2001 7:39, James Reeves wrote:
> I've started work on the man page btw, just so that we don't duplicate each
> others work.

Oh, wow.  Thanks.  Could you give me information on how to compile it so that 
I can put it in the Makefile?

> We also need to figure out who needs to work on what; at the moment I seem
> to be just tidying up things generally, although to be fair I suppose we've
> got most of the features for v2.0 in already :)

We do?  You'd better hurry up and cvs commit them!!  <g>

1.9 needs some polishing, that's it.  Stuff like the --quiet feature and 
better management of strings.

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

Re: [ID] proc_list_parm and the future

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

> > (note my use of strrchr as opposed to strchr)
>
> With Getline, it shouldn't matter, as `\n` is always at the end.

But this might be faster, I guess...
Err, not, actually it'll be slower.  I'll change it back.  Whoops.  This way 
it'll have to scan for both the end and then for the newline.

> We might also want to default to the $EDITOR environment value if the
> editor field in't defined and $EDITOR is set.

This goes in globals.c, in init_globals.

> I would just put all the editing and script stuff into editing.c, as they
> tend to fall under the same catagory.

Yah, okay.

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

Re: [ID] Powerful new functions

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

> > fprintf_list(db_file, old_files, "# OLD # %!s\n");
> >
> > Nice?  And you can put more stuff after the format string, as usual.  But
> > refer to them with ordinary % tags.
>
> Very nice, although it took me a while to work out what the code was doing
> (and you complain my code is difficult to read :-) - Is it finished at your
> end, because the cvs version has a `fail("fprintf_list ain't ready!")`?

I'm not done at all.  I doubt it runs yet, even without that fail thing.  I 
just decided it was time to try to sleep.  I should have just kept on 
working, because it was impossible to go to sleep until 5 a.m.--my house was 
too busy all night, but I don't think I should say why on a public forum.

One obvious deficiency is that it doesn't actually process every node in the 
list.  It doesn't process any node, for that matter.

> > Next, there's char* safe_sprintf(char** to, int* to_cap, char* fmt, ...).
> > It's a version of sprintf that can reallocate the destination string to
> > be just the right size.  Example:
> >
> > safe_sprintf(&chroot_filename, &chroot_namelen, "%s/%s", root, cwd);
>
> That'll be a nice & flexible replacement for dir_paste, at least, as well
> as being handy in quite a few other places in the code.

Combine it with replace(&path, &path_cap, "//", "/");, and the string'll be 
ready to output to the screen and the log files.  opendir will still work 
with //dir/a///b//, right?

> > Currently, they're in list.c, but their final homes will
> > probably be elsewhere, possibly in a string-handling source file. 
> > Strings are getting clumsy, because since we're worried about avoiding
> > buffer overruns, we're keeping a capacity integer with every char* that
> > could possibly grow, so maybe we should create a string struct, like so:
> >
> > typedef struct String {
> >    char* data;
> >    int cap;
> > } String;
> >
> > And then we can make some simple interface functions, like:
> >
> > void ensure_that_the_string_is_big_enough_for_this(String* str, int len)
> > {
> >    if (len > str->cap) {
> >       str->data = realloc(str->data, len);
> >       str->cap = len;
> >    }
> > }
> >
> > Tell me your thoughts.
>
> Hmmm, the general idea's sound, but I'm wondering if we can't cut down on
> the amount of mallocs around.

I know.  We have a ton.  All this realloc'ing nonsense started with 
dir_paste.  Now maybe we can hide it some.  Also we can make it allocate more 
than necessary to reduce multiple reallocs.

> Perhaps the filename storage for find_newer
> could be stored in just one memory slot, PATH_MAX long,

I'm hesitant to trust PATH_MAX, but maybe it's okay.

linux/limits.h:#define PATH_MAX        4095     /* # chars in a path name */

We can preallocate buffers of this size to pass to the stringy functions.

> or two if you're
> going to include chroot_filename. That way you could cut down on the amount
> of memory fiddled about with. I'll have to look more into this for
> cross-platform compatibility, but what do you think about the general idea?
>
> Actually, I'm not so sure about that approach now; the 'find' source seems
> to do the same thing as we're doing, though using realloc more. It all
> really depends on how well the heap is handled.

With the better-written functions, the buffer is reused.  But we should have 
a jump value to increase the buffer by.  The stl doubles the size at 
reallocation time... should we do the same?

> Let's keep it the way it is at the moment, and I'll keep an eye out for a
> beter solution, if there is one.

Trust me, I'll be working this issue.  I like to plink away at the functions 
until I can't see anything more that needs to be done.

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

Re: [ID] Couple minor issues

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

> > Good.  That means that the only link we could possibly follow is a
> > mounted directory, and like I said earlier we're not likely to run into
> > those. Still, we might put a warning in the documentation somewhere, or
> > automatically eject the offending hard disk.  Hey, since we're probably
> > running as root (are we??  we don't *have* to be...), we have
> > kernel-given permission to do so.
>
> Probably be best to assume anyone who mounts a directory like this knows
> what they're doing! :)

Maybe we had better wait until a real user reports a problem.

> > It has been made slower still by calculating both a chroot name and a
> > real name for every file, even if root == "/".  If we had some profiling
> > gear, maybe we could check to see if it's better to calculate this every
> > time or use an if.
>
> Be difficult with hard drives, as the time to find files varies on the spin
> of the drive.

Yeah, maybe the delay caused by calculating an additional name is absorbed by 
this.

> You could always have a bool that is set when root != "/",
> that way it would be quite quick to check whether to include a
> chroot_filename.

Yeah, maybe.  Maybe in this case (the most common one), chroot_filename can 
be made to point to the ordinary filename.

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

Re: [ID] Man Page

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

On Sun, Jul 29, 2001 at 01:39:26PM +0100, James Reeves wrote:
> be just tidying up things generally, although to be fair I suppose we've got
> most of the features for v2.0 in already :)

Correction: v1.9 :)

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

Re: [ID] Man Page

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

On Sun, Jul 29, 2001 at 01:39:26PM +0100, James Reeves wrote:
> I've started work on the man page btw, just so that we don't duplicate each
> others work.

Added manpage (use man ./install-log.1 to view), and a small function in
config.c that'll set root to $LFS (if set) and editor to $EDITOR (again, if
set). Obviously the environmental variables are pretty low-priority and so can
be overwritten at the command line and in the rc.

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

[ID] Man Page

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

I've started work on the man page btw, just so that we don't duplicate each
others work.

We also need to figure out who needs to work on what; at the moment I seem to
be just tidying up things generally, although to be fair I suppose we've got
most of the features for v2.0 in already :)

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

Re: [ID] proc_list_parm and the future

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

On Sat, Jul 28, 2001 at 10:33:37PM -0500, Andy Goth wrote:
> I had to revert two of your changes.  It was nothing big, but you added some 
> extra parentheses in one line, which failed to increase readability but made 
> the line longer than 80 characters.  No biggie.  And I removed your 
> strip_newline function because it was so simple that I was able to replace 
> the one time you call it with just a single line of code:
> 
> *strrchr(buf, '\n') = 0;    /* Strip trailing newline */

Ok, that makes sense.
 
> (note my use of strrchr as opposed to strchr)

With Getline, it shouldn't matter, as `\n` is always at the end.

> I'm thinking about the if (edit) system(editor); clause of main.  I think it 
> should all go inside a wrapper function, so that main is kept clean.  But in 
> which source file should it go?  I'm thinking editor.c or something similar, 
> because we'll need to call it several times in version 2, for editing the 
> install script and so on.  There'll need to be support functionality such as 
> creating the default script (script.c?), readying it for editing, and picking 
> up on the changes brought on by the editor.

We might also want to default to the $EDITOR environment value if the editor
field in't defined and $EDITOR is set.

> Please suggest a better layout.  I don't want to spread junk out too much, 
> but I also don't want to need to move functions later on when we realize that 
> with all their helper functions they have grown too huge to not be their own 
> source file.

I would just put all the editing and script stuff into editing.c, as they tend
to fall under the same catagory.

> I'd like to make a 1.9 release, which'll be the final version of install-log 
> that operates like install-log.sh (versions 0, 1, and 1.1 - 1.4).  Then both 
> of our users can play with it some and point out bugs in it.
> 
> After 1.9, we'll add most of that functionality we discussed, and when it's 
> ready we'll call it 2.0.

That was more or less how I figured it would go anyway.

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

Re: [ID] Powerful new functions

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

On Sun, Jul 29, 2001 at 01:37:34AM -0500, Andy Goth wrote:
> First, there's void fprintf_list(FILE* file, List* list, char* fmt, ...).  It 
> works like fprintf, except that you can put %! tags in the format string, and 
> it'll replace them with the node data.  Yeah, it'll operate once for every 
> node, like proc_list.  Example:
> 
> fprintf_list(db_file, old_files, "# OLD # %!s\n");
>
> Nice?  And you can put more stuff after the format string, as usual.  But 
> refer to them with ordinary % tags.

Very nice, although it took me a while to work out what the code was doing (and
you complain my code is difficult to read :-) - Is it finished at your end,
because the cvs version has a `fail("fprintf_list ain't ready!")`?  

> Next, there's char* safe_sprintf(char** to, int* to_cap, char* fmt, ...).  
> It's a version of sprintf that can reallocate the destination string to be 
> just the right size.  Example:
> 
> safe_sprintf(&chroot_filename, &chroot_namelen, "%s/%s", root, cwd);

That'll be a nice & flexible replacement for dir_paste, at least, as well as
being handy in quite a few other places in the code.
 
> Finally, void replace(char** context, int* context_cap, char* from, char* to).
> It replaces "from" with "to" in *context, but it also reallocates everything 
> as necessary.  Examples:
> 
> replace(&path, &path_cap, "//", "/");
> replace(&exp_token, &exp_token_cap, "%", "%%");
> replace(&buf, &buf_cap, "\n", "\0");
> 
> Nifty, or what??  

Very nifty :)

> Currently, they're in list.c, but their final homes will 
> probably be elsewhere, possibly in a string-handling source file.  Strings 
> are getting clumsy, because since we're worried about avoiding buffer 
> overruns, we're keeping a capacity integer with every char* that could 
> possibly grow, so maybe we should create a string struct, like so:
> 
> typedef struct String {
>    char* data;
>    int cap;
> } String;
> 
> And then we can make some simple interface functions, like:
> 
> void ensure_that_the_string_is_big_enough_for_this(String* str, int len)
> {
>    if (len > str->cap) {
>       str->data = realloc(str->data, len);
>       str->cap = len;
>    }
> }
> 
> Tell me your thoughts.

Hmmm, the general idea's sound, but I'm wondering if we can't cut down on the
amount of mallocs around. Perhaps the filename storage for find_newer could be
stored in just one memory slot, PATH_MAX long, or two if you're going to
include chroot_filename. That way you could cut down on the amount of memory
fiddled about with. I'll have to look more into this for cross-platform
compatibility, but what do you think about the general idea?

Actually, I'm not so sure about that approach now; the 'find' source seems to
do the same thing as we're doing, though using realloc more. It all really depends on how well the heap is handled.

Let's keep it the way it is at the moment, and I'll keep an eye out for a beter solution, if there is one.

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

[ID] website

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

I modified the install-log website a tad, preannouncing 1.9.  That's 
<http://install-log.sourceforge.net/>, for those of you looking on.

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

[ID] Powerful new functions

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

I have written three really useful functions, but they're not quite done.  
They're still a mess; I haven't had enough time to "perfect" them.  But I'll 
upload them anyway because (1) everything still compiles and runs fine and 
(2) you need to see them.

Yeah, they're that good.

First, there's void fprintf_list(FILE* file, List* list, char* fmt, ...).  It 
works like fprintf, except that you can put %! tags in the format string, and 
it'll replace them with the node data.  Yeah, it'll operate once for every 
node, like proc_list.  Example:

fprintf_list(db_file, old_files, "# OLD # %!s\n");

Nice?  And you can put more stuff after the format string, as usual.  But 
refer to them with ordinary % tags.

Next, there's char* safe_sprintf(char** to, int* to_cap, char* fmt, ...).  
It's a version of sprintf that can reallocate the destination string to be 
just the right size.  Example:

safe_sprintf(&chroot_filename, &chroot_namelen, "%s/%s", root, cwd);

Finally, void replace(char** context, int* context_cap, char* from, char* to).
It replaces "from" with "to" in *context, but it also reallocates everything 
as necessary.  Examples:

replace(&path, &path_cap, "//", "/");
replace(&exp_token, &exp_token_cap, "%", "%%");
replace(&buf, &buf_cap, "\n", "\0");

Nifty, or what??  Currently, they're in list.c, but their final homes will 
probably be elsewhere, possibly in a string-handling source file.  Strings 
are getting clumsy, because since we're worried about avoiding buffer 
overruns, we're keeping a capacity integer with every char* that could 
possibly grow, so maybe we should create a string struct, like so:

typedef struct String {
   char* data;
   int cap;
} String;

And then we can make some simple interface functions, like:

void ensure_that_the_string_is_big_enough_for_this(String* str, int len)
{
   if (len > str->cap) {
      str->data = realloc(str->data, len);
      str->cap = len;
   }
}

Tell me your thoughts.

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

[ID] proc_list_parm and the future

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

... has been added.   It takes a void* and passes it on like I said.  
Currently I only use it once (okay, three times in a row), but I use that 
void* like an int.  And it compiles fine.

(Yes, both proc_list_parm and the future have been added!)

I had to revert two of your changes.  It was nothing big, but you added some 
extra parentheses in one line, which failed to increase readability but made 
the line longer than 80 characters.  No biggie.  And I removed your 
strip_newline function because it was so simple that I was able to replace 
the one time you call it with just a single line of code:

*strrchr(buf, '\n') = 0;    /* Strip trailing newline */

If we find that we're calling it more than once, we can bring it back.  
Having wrapper functions for everything is fine for the highest level 
stuff--main and some of the functions it calls--but the lower level dirtywork 
functions don't need help like this.

(note my use of strrchr as opposed to strchr)

I'm thinking about the if (edit) system(editor); clause of main.  I think it 
should all go inside a wrapper function, so that main is kept clean.  But in 
which source file should it go?  I'm thinking editor.c or something similar, 
because we'll need to call it several times in version 2, for editing the 
install script and so on.  There'll need to be support functionality such as 
creating the default script (script.c?), readying it for editing, and picking 
up on the changes brought on by the editor.

Please suggest a better layout.  I don't want to spread junk out too much, 
but I also don't want to need to move functions later on when we realize that 
with all their helper functions they have grown too huge to not be their own 
source file.

I'd like to make a 1.9 release, which'll be the final version of install-log 
that operates like install-log.sh (versions 0, 1, and 1.1 - 1.4).  Then both 
of our users can play with it some and point out bugs in it.

After 1.9, we'll add most of that functionality we discussed, and when it's 
ready we'll call it 2.0.

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

Re: [ID] # Old # and # Del #

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

> > > > > Oh, and I added a strip_end_newline() into util.c for reasons you
> > > > > can probably guess :),
> > > >
> > > > What?
> > >
> > > Getline grabs the end \n as well :)
> >
> > Oh, okay.  I have functionality for that in config.c, except that it
> > strips whitespace from both the beginning and the end of a given string.
>
> I noticed :) - the strip_end_newline was for the read_db function, or is
> that what you meant by "Oh, okay"?

The Oh, okay was for your explanation of where the newlines were coming from. 
 I've been so sleepy all day that I haven't been able to examine your 
changes.  I got as far as opening a browser window at the cvs repository and 
sorting by author, but that's it.

Maybe now I can resume perusing your work.

...

I actually have some other work here that's waiting on this project.  I have 
two Linux installations to do.  One of them is on this computer, using new 
versions of core libraries.  The other is for another computer I have, 
compiled for the 486 and focused on routing and security.
-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] # Old # and # Del #

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

On Sat, Jul 28, 2001 at 05:41:32PM -0500, Andy Goth wrote:
> On Saturday, July 28, 2001 4:05, you wrote:
> > On Sat, Jul 28, 2001 at 02:07:54PM -0500, Andy Goth wrote:
> > > > Oh, and I added a strip_end_newline() into util.c for reasons you can
> > > > probably guess :),
> > >
> > > What?
> >
> > Getline grabs the end \n as well :)
> 
> Oh, okay.  I have functionality for that in config.c, except that it strips 
> whitespace from both the beginning and the end of a given string.

I noticed :) - the strip_end_newline was for the read_db function, or is that
what you meant by "Oh, okay"?

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

Re: [ID] # Old # and # Del #

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

On Saturday, July 28, 2001 4:05, you wrote:
> On Sat, Jul 28, 2001 at 02:07:54PM -0500, Andy Goth wrote:
> > > Oh, and I added a strip_end_newline() into util.c for reasons you can
> > > probably guess :),
> >
> > What?
>
> Getline grabs the end \n as well :)

Oh, okay.  I have functionality for that in config.c, except that it strips 
whitespace from both the beginning and the end of a given string.

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

Re: [ID] # Old # and # Del #

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

On Sat, Jul 28, 2001 at 02:07:54PM -0500, Andy Goth wrote:
> > Oh, and I added a strip_end_newline() into util.c for reasons you can
> > probably guess :),
> 
> What?

Getline grabs the end \n as well :)
 
-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] # Old # and # Del #

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

> > Check out the TODO list in install-log.c.  For proc_list, I'm considering
> > passing a va_list to the function.  What do you think?  Would that be too
> > clumsy?
>
> Sounds ok to me. I'm quite rusty on va_lists, so you're probably better
> qualified to call this one :)

va_lists may be too hard, because in using them they are changed.  We'd have 
to create a new one for every invocation of the function that list_proc 
calls.  So that leaves us with... a void*?  I guess we need a list_proc_parm 
that passes one.  I suppose it would be okay to cast it like so...

void proc(List* node, void* data)
{
   printf("%s: %i\n", (char*)node->data, (int)data);
}

I mean, we already do with node's void*.

Uhm, can plain "void" be used for a variable type?  Something that must be 
cast to something else before use?  void* implies a pointer, but sometimes 
the data to pass is so simple that it can be passed through the stack by 
value rather than by pointer.

> > Please test it for me.  Use the --root option so that you don't clobber
> > your system-wide install-log database.  Pretend to install a package
> > (just touch three files, really), and then delete one, touch one, and
> > leave the third one alone, and finally run install-log --force with the
> > same package name.  Read the database and see if it worked.
>
> I've added some error checking to the opendir function in find_newer, as
> otherwise if people make a mistake in typing in the includes, they just get
> a segmentation fault.

I'll be sure to cvs update.

> The read_db function work ok, once I put in the right headers for stat, and
> tidied out a few other bugs (like "if (db_file = NULL) fail...", nice to
> know the classic "= not ==" trips up other people than me :).

I'm just doing my job to make you not feel COMPLETELY stupid. <g>

> I also discovered that stat may need a proper buffer to point to if the
> file exists - stat(filename, NULL) flung up some segmentation faults when
> it found the file (probably trying to access NULL->st_mtime or something)
> until I gave it a proper buffer. I wonder if there's a better function for
> telling if files exist...

I told you, I haven't tested that stuff.  Check the timestamps and adjust for 
the fact that my clock's set to Chicago time.

> Oh, and I added a strip_end_newline() into util.c for reasons you can
> probably guess :),

What?

> and changed add_old_and_del_file to take into account
> the root.

Oh, oops.  I don't exactly like that add_old_and_del_file function, though.  
Maybe all it needs is a better name. ;^)

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

Re: [ID] Harmless (?) bug

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

On Saturday, July 28, 2001 9:51, you wrote:
> On Fri, Jul 27, 2001 at 09:07:56PM -0500, Andy Goth wrote:
> > One harmless bug I see is the case of --exclude="".  For this,
> > install-log will generate a list of *one* entry, a zero-length string. 
> > But this is okay because no exclude search will match it.
> >
> > Should I go through the trouble of culling all zero-length strings from
> > include and exclude?
>
> It's wouldn't take too long to check: if (!*filename) return; Although its
> not much of a bug, so you could always try fixing it later on :)

It's already fixed, in set_option in config.c.  Simple if.  So long as 
zero-length lists work, this'll work.

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

Re: [ID] database.c

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

On Fri, Jul 27, 2001 at 12:25:26PM -0500, Andy Goth wrote:
> Speaking of man pages, how does one write one of those things?  They're 
> really nice to have, but I've never seen a guide on how to write one!

Man pages are apparently written in groff syntax, so you could try searching
for that on google. Alternatively there's Manedit
(http://wolfpack.twu.net/ManEdit/) which converts an simpler xml-type format
into the more complecated groff, and also provides some basic templates. I'm
downloading it now :)

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

Re: [ID] Include list

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

On Fri, Jul 27, 2001 at 12:22:55PM -0500, Andy Goth wrote:
> > which is rather ad hoc :) - hopefully I can try and learn some good habits
> > from this project.
> 
> Sure, take whatever you like from this project.  It's gpl, so you're 
> certainly not forbidden from learning from it.
> 
> Heh, I'd hate to sign a nda, read some source code, find some good ideas (or 
> stylings), and then pretend they didn't exist when trying to write my own 
> code!  (I doubt ndas are *that* bad.)

Microsoft Shared License, 2005:
1) Any thinking about the code out of designated times is forbidden.
2) Any learning while looking at the code is forbidden.
3) Any good ideas you may have are the sole property of Microsoft.
4) We *own* you.

:)


> > > Okay, since you're working on the find_newer function, could you tell me
> > > how you plan on handling symlinks to directories and (much harder?)
> > > mounted directories?
> >
> > Symlinks should really be treated as files.
> 
> Currently, you don't follow symlinks, I think.  You use lstat, so you should 
> be able to see a symlink for what it really is.  But, will that ISDIR thing 
> say that a symlinked directory is a directory?  

Nope, I checked before I wrote logger.c in a small test program.

> > If a install process puts them
> > in, they should be listed in the logs ideally.
> 
> I believe that in install-log.sh I skipped listing directories.

Directories, yes, but I was really talking about symlinks. Like an install
process installing /bin/bash and symlinking /bin/sh to it.

> > Treating them as directories
> > opens the way for infinite loops, and besides, if symlinks were followed
> > you'd be logging the same thing twice, as the hardlink should surfice.
> 
> Surfice?  Made-up word?

Oops, forgot to run spell-checker. I'm not exactly the worlds best speller
anyway :)

On the other hand, spell checkers suck on documents with a lot of code and
technical stuff in anyway.

> > Unfortunately what do you do if you want to exclude /usr/src/linux? Ideally
> > the program would have to check if it had already been into the symlinked
> > dir, and make a decision on that, or is this going too far?
> 
> This would be hard to code.  If it finds the excluded symlink first, it might 
> be able to note that it skip what it points to, but if things happen the 
> other way around, install-log can't possibly work as expected.  So let's 
> slate this as a version 12 feature.

That's what I thought.

> > Should we
> > restrict includes/excludes to real directories only?
> 
> Sort of.  When symlinks are listed in exclude, they'll just get skipped.
> 
> Oh, forgot to tell you, the way I have find_newer written, it should be able 
> to exclude individual files.  It checks exclude for every file, not just 
> every invocation of find_newer (like you had it), so things may be slower, 
> but on the other hand exclude lists don't get too long when there's an 
> include list. ;^)  I haven't played with this side effect yet, though, so 
> that's your job.

It seems to work ok so far :) - it doesn't take too long to complete the scan.
If I think of a way to speed it up though, I'll be sure to include it.

> > Woah! That was close! Almost did a rm -rf on ./jim, my mounted home dir.
> > Must be this heat getting to me :)
> 
> Bindmounting?

Yep. Not exactly the best idea to try and wipe $HOME. I'd better get some of
these files backed up, actually...

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

Re: [ID] chroot quandary

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

On Fri, Jul 27, 2001 at 08:50:34PM -0500, Andy Goth wrote:
> The issue is configuration parsing.
> (1) Defaults built into executable
> (2) Configuration file
> (3) Command line
> 
> Uhm, I'm confused.  The only solution I can think of is adding an internal 
> priority counter to configuration settings.  Initially it's zero.  When set 
> from the configuration file, it's set to one.  When set from the command 
> line, it's two.  If an attempt is made to set an option with a higher 
> priority (i.e. overriding a command line option from the configuration file 
> [when scanned the second time]), nothing happens.

I can't really think of any other way to handle this, a priority counter might
very well be necessary.
 
> Furthermore, the ROOT entry cannot be set from the configuration file.  This 
> removes the possibility of scanning more than two configuration files and the 
> possibility of getting into an infinite loop (with two pointing at each 
> other).
> 
> I'll try implementing this.  If you see anything that needs to be fixed in 
> this scheme, share, and we'll go back to the old version and do it Right.

Ok, I can't think of many instances where you would really want to set ROOT in
the config, and a user could always alias it in the shell I suppose. If I think
of something though, I'll be sure to say :)

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

Re: [ID] Harmless (?) bug

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

On Fri, Jul 27, 2001 at 09:07:56PM -0500, Andy Goth wrote:
> One harmless bug I see is the case of --exclude="".  For this, install-log 
> will generate a list of *one* entry, a zero-length string.  But this is okay 
> because no exclude search will match it.
> 
> Should I go through the trouble of culling all zero-length strings from 
> include and exclude?

It's wouldn't take too long to check: if (!*filename) return; Although its not
much of a bug, so you could always try fixing it later on :)

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