RE: includes inside squid.conf

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@squid-cache.org]
> Sent: Tuesday, April 02, 2002 6:28 AM
> To: Andres Kroonmaa
> Cc: squid-dev@squid-cache.org
> Subject: Re: includes inside squid.conf
>
>
> On Monday 01 April 2002 19:43, Andres Kroonmaa wrote:
>
> > No-no, why? You never tell user about inode, you just tell
> him that
> > this filename has already been included once. Thats it.
> When bailing
> > out, you can show every file being currently open while exiting
> > recursion. Inodes just simplifies it for a coder, skipping
> the need to
> > expand any filename into absolute path. Thats left to the OS. How
> > would you do that yourself, portably?
>
> If you want to support relative path names then you better define how
> these are to be translated into absolute path names, and make this
> translation when processing the files.

The -I concept from compiler-land would serve us well.. I don't think
it's needed though.

This is (for interest) the code from the pluggable configuration parser
to do includes. It worked very well for me, and adding simple loop
detection is as simple as adding a strcasecmp to the list walking loop.
There are a couple of minor changes needed to ParseConfigFile to make it
happily reentrant, but that's trivial (and can be grabbed from cvs as
well if needed).

===
CBDATA_TYPE(includefile_t);

static void
parse_include(parserNameNode *parserName, void * data)
{
    includefile_t **includefile=(includefile_t **)data;
    includefile_t *link,*tmp_link;
    char *tempstr=NULL;
    if (! *includefile)
        CBDATA_INIT_TYPE(includefile_t);

    parse_eol(parserName, &tempstr);

    link=*includefile;
    while (link && link->next)
        link=link->next;
 
    tmp_link=cbdataAlloc(includefile_t);
    tmp_link->next=NULL;
    tmp_link->filename=tempstr;

    if (link)
        link->next=tmp_link;
    else
        *includefile=tmp_link;

    parseConfigFile(tmp_link->filename);
}

static void
free_include(parserNameNode *parserName, void * data)
{
    /* we don't need to process the file data, just free the linked list
*/
    includefile_t **includefile=(includefile_t **)data;
    includefile_t *link;
    while (*includefile) {
        free_eol(parserName, &(*includefile)->filename);
        link=(*includefile)->next;
        cbdataFree(*includefile);
        *includefile=link;
    }
}

static void
dump_include(StoreEntry * entry, const char *name, void const * const
data)
{
    includefile_t *link=*(includefile_t **)data;
    while (link) {
        storeAppendPrintf(entry,"%s %s\n",name,link->filename);
        link=link->next;
    }
}
====

> > If your opinion comes from wish to keep it similar to C processing,
> > then I agree. But it would be really lovely to be able to keep all
> > swap disk related config on that disk itself and include it as
> > optional when found suitable.
>
> I have a very strong opinion on this:
>
> If you want conditional configuration dependent on external resources
> then use a conditional pre-processor, or, if you for some unknown
> reason dislike pre-processors, use a configuration file language with
> simple "if-else" constructs giving you the needed conditions..
>
> But then all our products are all built around a configuration engine
> with a very suitable for writing configuration file templates and web
> interfaces, having all of the needed include, if-else, loops,
> variables etc.. so my bias is perhaps slightly differen than most
> Squid administrators..

I agree with Alex here - the parser should push errors back up, and the
caller can decide. IMO though, the config for the disks should not be
on the disks themselves, so that isn't an issue for the parser in
anycase.
 
Rob
Received on Mon Apr 01 2002 - 14:17:07 MST