help-cfengine
[Top][All Lists]
Advanced

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

Re: syntax reference


From: Roy Marantz
Subject: Re: syntax reference
Date: 21 Sep 2001 14:01:11 -0000

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




reply via email to

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