help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: syntax reference


From: Mark Burgess
Subject: Re: syntax reference
Date: Fri, 21 Sep 2001 16:51:13 +0200 (MET DST)

Yes, this is a nice summary. Could I put it into a cfdb newsbite?

I would like to try to do something with the documentation before
long.....so hard, so little time.....sigh...

M

> 
> Thanks for the info.  I already knew most of that from the docs, but
> you stated it in a nice clear way.  My question was prompted by
> problems I had trying to debug a macro/variable use in an editfiles:
> LocateLineNotMatching.  I think I found a way around it, but now that
> I know it is supposed to work, I can try again.  I sure wish there was
> some way to see the lines after macro substitution has taken place.  I
> haven't found that in the debugging output even.  Thanks again.
> 
> Roy
> 
>    Date: Fri, 14 Sep 2001 22:34:20 -0400 (GMT+4)
>    From: Chris Edillon <jce@zot.com>
>    cc: help-cfengine@gnu.org, marantz@nbcs.rutgers.edu
> 
>    On 14 Sep 2001, Roy Marantz wrote:
> 
>    > Does anyone know of a detailed description of the syntax of cfengine,
>    > say in some kind of BNF or somthing?  I'm using (with varying degrees
>    > of success) version 1.6.3.  In particular I keeping running into
>    > problems with macros/variables such as how to define them (in a groups
>    > part and/or module) and where they get expanded.  I'd love there to be
>    > a way to include the contents of a variable in a REGEX, but I don't
>    > see one.  I'm trying to avoid pouring over the source, so any help
>    > would be appreciated.  Thanks in advance.
>    > 
>      don't know of any grammar description; mark would be the one to
>    as about that i guess.  however, i can try to answer your questions
>    on macros.
> 
>      macros or variables are defined under the control: section of a
>    cfengine script using the following syntax:
> 
>        variable = ( value )
> 
>    in general, whitespace should be used around the open and close
>    parentheses so that the parser doesn't get confused (per the
>    documentation, and i've seen problems when it isn't used).  for
>    values containing whitespace, the value can be quoted:
> 
>        variable = ( "has whitespace" )
> 
>    values can also come from the output of an arbitrary executable:
> 
>        variable = ( "exec /bin/domainname" )
> 
>    the full path to the executable must be used, or else cfengine
>    considers the quoted string to be exactly that: a string.  given
>    the following:
> 
>        host = ( "exec hostname" )
> 
>    the variable $(host) contains the value "exec hostname" and not
>    the machine's hostname.  executing a single binary/script is the
>    norm; as adrian phillips mentions in a previous post, piplining
>    can be done but you have to use a few tricks.
> 
>      note that defining a variable looks very similar to defining
>    a new class, which can be confusing at first.  classes are all
>    defined under a classes: or groups: section, whereas variables
>    or macros are defined only under a control: section.
> 
>      once you've defined a variable, you reference it with the form
>    $(variable) or ${variable}.  the parentheses or braces are
>    mandatory.  as far as i can determine from testing, you can use
>    a variable anywhere in a cfengine script, as i believe that
>    variable substitution is done during or just after parsing, and
>    before any actions are taken.  for a definitive answer, though,
>    you'd have to check the source (or ask mark).
> 
>      so, you can in fact use a variable in a regex.  the following
>    works just fine for me:
> 
>        control:
>          actionsequence = ( editfiles )
>          var1 = ( foo )
> 
>        editfiles:
>          any::
>              { /tmp/testfile
>                DeleteLinesMatching "^$(var1).*"
>              }
> 
>    it acts as expected and deletes any lines beginning with "foo"
>    in /tmp/testfile.  you can even do things like this:
> 
>        control:
>          actionsequence = ( editfiles )
>          passwd = ( /etc/passwd )
> 
>        editfiles:
>          any::
>              { $(passwd)
>                DeleteLinesMatching "^fred:.*"
>              }
> 
>    this comes in handy when you work in a heterogenous environment
>    in which different operating systems have different names/paths
>    for the same files.  for example, on solaris /etc/vfstab is in
>    general the same as /etc/fstab everywhere else.  so instead of
>    doing two separate editfiles rules to add something to these
>    files:
> 
>        editfiles:
>          solaris::
>              { /etc/vfstab
>                # do some complicated edit
>              }
> 
>          !solaris::
>              { /etc/fstab
>                # do same edit
>              }
> 
>    you could make your edit rule more generic and your script less
>    messy using a variable:
> 
>        control:
>         solaris::    fstab = ( /etc/vfstab )
>         !solaris::   fstab = ( /etc/fstab )
> 
>        editfiles:
>          any::
>              { $(fstab)
>                # do some complicated edit
>              }
> 
>    granted, this is a contrived example, but i use this at work
>    all the time for enumerating init script locations (/etc/init.d
>    on most unix systems, /sbin/init.d on OSF1 or HP-UX,
>    /etc/rc.d/init.d on redhat or mandrake, etc.), doing the same
>    edit on files with different names/paths according to OS, or
>    what have you.  since the environment i work in consists of
> 
>      ok, so that was a bit long-winded, but i hope it helps you out
>    in some way.  :-)
> 
>    chris
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine
> 



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




reply via email to

[Prev in Thread] Current Thread [Next in Thread]