help-cfengine
[Top][All Lists]
Advanced

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

macro expansion confusion


From: Marion Hakanson
Subject: macro expansion confusion
Date: Tue, 27 Aug 2002 17:18:51 -0700

Folks,

This behavior looks like a bug, but I'm asking here if anyone else has
run across this issue.  I'm running cfengine-1.5.4 and 2.0.3 on both
Solaris-2.6 and Solaris-8.  Here's a minimal config file to demonstrate:

############cut here##################################################

control:

        actionsequence = ( directories )
        init_sys = ( "/etc/init.d" )
        sunos_5_6::
            cfst_init_base = ( "$(init_sys)/local/" )   # Trailing slash, yes.
        !sunos_5_6::
            cfst_init_base = ( "$(init_sys)/CFST" )     # No trailing slash.
        any::
            cfst_init_basedir = ( "exec /usr/bin/dirname $(cfst_init_base)X" )


directories:
        #
        # make sure our local init scripts have a home
        #
        $(cfst_init_basedir)            mode=755 owner=root group=root

############cut here##################################################



What happens is that when run with "cfagent -n -v", the above file
prints out the following message, indicating a failure, or that at
least cfengine is trying to do something unintended:

  . . .
  ---------------------------------------------------------------------
  Checking directories:
  ---------------------------------------------------------------------
  
  MakePath(exec /usr/bin/dirname /etc/init.d/local/X)
  cfengine:backbone: Cannot stat /exec /usr/bin/dirname /etc/init.d/local/X/.
  . . .


This implies that the macro has not been fully expanded.  However, if
you lose the "-n" and run it for real, things actually work OK:

  . . .
  ---------------------------------------------------------------------
  Checking directories:
  ---------------------------------------------------------------------
  
  MakePath(/etc/init.d/local)
  . . .



As I mentioned, both 1.5.4 and 2.0.3 behave identically with this input
file.  It has certainly caused confusion when testing and debugging, and
I'm wondering if others have run across this behavior, and/or if there
is a patch available.

Thanks and regards,

-- 
Marion Hakanson <hakanson@cse.ogi.edu>
CSE Computing Facilities






reply via email to

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