Re: Getting $(allclasses) into a shellcommand

[John Sechrest]

Ed Brown <ebrown@lanl.gov> writes:

 % To back up a little, and to try to understand this thread a little
 % better, it seems like it should be said that being able to pass
 % $(allclasses) to another script works just fine, except when it grows
 % very long.  

 % 1. What are the limits we are talking about?  Buffer sizes in cfengine? 
 % Bash command line limits?  Without knowing what the problem is, it's
 % hard to weigh some of the solutions that have been offered.  

I believe it is a function of the Shell Buffer sizes. 


 % 2. When do too-long $(allclasses) strings get created?  So far, I've
 % only seen it mentioned with respect to 'packages:'.  Defining classes is
 % the only action available in 'packages:'.  It would be great if you
 % could execute arbitrary commands, as in 'processes:'.  This could help
 % eliminate some of the need to rely on class definitions.  This
 % possibility was discussed in a thread several months ago,
 % http://lists.gnu.org/archive/html/help-cfengine/2003-11/msg00061.html
 % , and I wonder if the implementation might still be in the works?? 
 % 
 % thanks,
 % Ed
 % 
 % 
 % On Tue, 2004-07-20 at 13:52, Ted Zlatanov wrote:
 % > On Tue, 20 Jul 2004, borwicjh@wfu.edu wrote:
 % > 
 % > Mark.Burgess@iu.hio.no wrote:
 % > >> I am interested in finding a different solution to this problem.
 % > >> Any ideas would be welcome.
 % > >> M
 % > > 
 % > > Could you add a new option to shellcommands that sends all the class
 % > > variables to STDIN?  E.g.
 % > > 
 % > > shellcommands:
 % > >    "/path/to/program" stdin=allclasses
 % > 
 % > I'm divided about this proposal.  On the one hand, it's elegant and
 % > very much in the Unix spirit.  On the other, it means cfengine can't
 % > use STDOUT for any other communications with the client program.
 % > 
 % > I propose the following:
 % > 
 % > 1) providing a "classoutput" option which can be "stdout," "file," or
 % >    nil (the default).  With "stdout" the above happens.  With "file"
 % >    the user can expect the name of the file in the CFCLASSOUTPUT
 % >    environment variable; the file contents will be as in (2).
 % > 
 % > 2) Some communication protocol between cfengine and programs it
 % >    spawns.  This should be synchronous, so the cfengine feed to the
 % >    child could be:
 % > 
 % > CFALLCLASSES=a
 % > CFALLCLASSES=b
 % > CFALLCLASSES=c
 % > CFALLCLASSES=d
 % > ...
 % > 
 % > CFSECTION=shellcommands
 % > CFPID=$$
 % > CFINSTALLABLECLASSES=a
 % > CFINSTALLABLECLASSES=b
 % > CFINSTALLABLECLASSES=c
 % > ...
 % > 
 % > The advantage of the format above is that it's pretty much standard
 % > Unix lingo, so parsing it is trivial for apps like Perl or shells.
 % > 
 % > We already have the "cfengine-die\n" protocol for communication back
 % > from the spawned program to cfengine :)
 % > 
 % > Ted
 % > 
 % > 
 % > _______________________________________________
 % > Help-cfengine mailing list
 % > Help-cfengine@gnu.org
 % > http://lists.gnu.org/mailman/listinfo/help-cfengine
 % 
 % 
 % 
 % _______________________________________________
 % Help-cfengine mailing list
 % Help-cfengine@gnu.org
 % http://lists.gnu.org/mailman/listinfo/help-cfengine

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest@peak.org
                                      .   
                                              . http://www.peak.org/~sechrest