[Top][All Lists]

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

Feature request: Ability to parse files with a custom parser

From: Knut Auvor Grythe
Subject: Feature request: Ability to parse files with a custom parser
Date: Wed, 16 Feb 2005 13:24:40 +0100
User-agent: Mutt/1.4.2i

I hope this is the right place to post this. The bug tracking system on
SourceForge did not look like it was in use.

I work for the IT Department on NTNU, Trondheim. We have some rather
complicated setups in our cfengine here, and need a way to generate config
files based on the classes defined on a client. It is a bit too
complicated for using EditFiles, I'm afraid.

What we use now is wrappers for a number of macro languages, M4 being the
most commonly used. Our wrappers read the $CFALLCLASSES environment
variable set by cfagent -u, and parse the file based on this information.

Right now, we solve this problem like in this somewhat simplified example:

    AddInstallable = ( generate_sshd_config )

        # Check if we need to regenerate the file
        generate_sshd_config = ( 
!ChangedBefore(/etc/sshd/sshd_config.m5,/etc/sshd/sshd_config) )


        "/local/admin/bin/m4wrap /etc/ssh/sshd_config.m4 /etc/ssh/sshd_config"

This approach has a number of disadvantages:
 * It is cumbersome and error-prone to do all this writing for each file
 * We re-implement a lot of cfengine functionality when testing if the
   file should be regenerated
 * A lot of M4 files have to lie around

What we would like to see, is an option in copy for using a custom parser,
like so:


This approach would eliminate all the problems stated above, plus it would
be an extremely flexible and powerful feature. I also think it looks
pretty easy to implement.

I can think of the following requirements to make such a feature useful:
 * Either pipe the file though the parser or give source and dest as
   arguments to it, depending on what is the easiest to implement
 * The $CFALLCLASSES variable must be defined (at least when using -u), so
   the wrapper has info about the classes defined on the machine

Checksumming might be a problem. Checksumming the output of the parser
would naturally work, but an ignorant solution causing the checking to
always fail when a parsecmd is defined would be good enough for me. It
probably just depends on how much one wants to put into it.

Does this look like a feature worth implementing? I would be eternally
grateful if it was :-)

Knut Auvor Grythe
ITEA Systemdrift

reply via email to

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