Re: wishlist item

[Chip Seraphine]

Just to contribute my $.02: The nice thing about keeping the class logic
in the cfengine script is that you do not need to reproduce it in every
external that needs to know about it.  Mark's example is fine if we just
want conditional execution, but not so helpful if the external (module,
shellcommand) takes action based on $CFALLCLASSES or whatever.

(As an example of that, I have a "complain"  tool that simply spits out
email messages if it sees certain [single] classes defined.  I have it set
up as a simple table; having this tool do actual logic would make it much
more complex.)

That being said, I generally work around the situation Akop describes by
doing this kludge:

control:
        foo.bar::
                addclasses= ( foobar )

The only problem with this is that it happens in the control section which
might not be where you'd want it (e.g. groups).

On Sat, 24 May 2003, Akop Pogosian wrote:

> On Sat, May 24, 2003 at 09:54:03AM +0200, Mark.Burgess@iu.hio.no wrote:
> > 
> > This doesn't seem terribly useful, since the class you define
> > is longer than the combination of the classes that define it. 
> > Why not just do:
> > 
> >  64_bit.clients::
> > 
> >     relevant actions ?
> >     
> 
> The derived class name is passed to a shell script in the shell
> commands section using the $(allclassess) variable. This script does
> not contain the logic for combining classes and, therefore, relies on
> cfengine for this (I thought that making the shell script do this
> would be reinventing the wheel).
> 
> 
> -akop
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine
>