[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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~