Forum: CFEngine Help Subject: Re: filecopy, transform with grep. Author: davidlee Link to topic: https://cfengine.com/forum/read.php?3,22985,23019#msg-23019
Thanks for your reply, Ben. I appreciate the discussion and your kindness! I still think my "grep" and the manual's "postfix" are closer than you suggest. Indeed, I still think that they are so close as to be almost indistinguishable. Correct me if I'm wrong, because I'm not too familiar with postfix aliases, although in a previous life I did years of hand-to-hand combat with sendmail aliases (although mostly automated through scripts I maintained). Doesn't the command "/etc/postfix/alias" take a read-only sourcefile and produce its own privately-formatted complete set of contents in a resultfile? And in the postfix example, cfengine itself isn't bothered about the exact contents of the resultfile, is it? The only thing that cfengine is bothered about in the postfix example is it has detected the trigger to perform an update (determined by the "doupdate/isnewerthan()" stuff) and, if that trigger is set, has run a "transformer" for the resultfile (including possible auto-create). That's correct, isn't it? cfengine, in this example in the manual, isn't concerned with the horrible details within "resultfile". That's correct, isn't it? cfengine itself isn't actually interacting at all with the contents of the resulting "alias.cdb" is it? So if my understanding of that "postfix" example is correct then why is my "grep -v string sourcefile" example any different, in principle? It's the same isn't it? With the one, and only, significant difference being that the output of the command goes to a different (and, it so happens, a more UNIX-natural) destination. Given that the two examples (the manual's postfix and my "any UNIX-writes-stdout" program) are only a whisker apart (that whisker being an explicit filename vs. stdout) then isn't my proposed additional single-line "transformer_stdout=>..." beautifully concise and clear, compared to any other alternative. And how would its internal implementation be any less clean than whatever code implements the existing scheme? (Indeed, it would be far cleaner than an earlier proposed idea for the user having to use an intermediate file, with the possible nasty lock/race conditions that might flow from that. (And that really WOULD be against cfengine principles!)) Thanks again for the discussion! _______________________________________________ Help-cfengine mailing list [email protected] https://cfengine.org/mailman/listinfo/help-cfengine
