As for the hard classes, what about reading /var/cfengine/state/allclasses.txt?
[jll...@gdcscf3lgmt01:/var/cfengine/state] cat allclasses.txt any Friday Hr22 Evening Min55 Min55_00 Q4 Hr22_Q4 Day8 January Yr2010 Lcycle_0 GMT_Hr22 linux <...snipped for brevity...> [jll...@gdcscf3lgmt01:/var/cfengine/state] -----Original Message----- From: help-cfengine-boun...@cfengine.org [mailto:help-cfengine-boun...@cfengine.org] On Behalf Of Paul Krizak Sent: Friday, January 22, 2010 12:31 PM To: nwat...@symcor.com Cc: help-cfengine@cfengine.org Subject: Re: wish list This is a great list. I have some comments inline below... Paul Krizak 7171 Southwest Pkwy MS B200.3A Senior Systems Engineer Austin, TX 78735 Advanced Micro Devices Desk: (512) 602-8775 Linux/Unix Systems Engineering Cell: (512) 791-0686 Silicon Design Division Fax: (512) 602-0468 On 01/22/10 13:02, nwat...@symcor.com wrote: > Greetings, > > Here are some things I'd like to see in future versions of Cf3. > > 1. A tool or command option to confirm an authentication handshake from > the client side. Currently one is forced to run the agent in verbose mode > > and search though the output for the H.A.I.L sections. It need not be > verbose enough to give anything away. Seconded. This tool could possibly even be used in cf.preconf to help correct common cases where authentication fails. > > 2. A way to have the agent output hard classes without parsing any inputs. I would expand this to also include any soft classes -- so you can run the agent all the way through the classes: section, and have it print out any classes that get defined before it starts diving into the actionsequence. Obviously this won't catch installable classes, but this would be a fantastic way to sanity-check that a server will get configured properly, as you'll be able to verify that the classes are getting defined properly. Running in --dry-run mode "sort of" does this, but since it doesn't execute anything a lot of the classes don't get defined like you'd expect. > > 3. The parser should be more white space agnostic in certain cases. For > example > ifvarclass = "one|two|three|four" might be easier to read if one could > write > ifvarclass = " > one| > two| > three| > four > " > > This is especially true when classes have longer names. > > Similarly it would be nice when defining variables if one could depense > with quotes and delimit by whitespace. > "x" slist => { > one > two > three > four > } Seconded -- avoiding the need for quotes when tokens match [a-zA-Z0-9_] would make things more readable. > > Alternatively keep the quotes but do away with the commas. > "x" slist => { > "one" > "two" > "three" > "four" > } I disagree; the commas I think are an important piece of the syntax here. > > Or an alternative alternative have the parser not baulk at an end of list > comma. > "x" slist => { > "one", > "two", > "three", > "four", #<-- Do not be a syntax error. > } Agreed. Perl behaves this way and it's very handy when you end up copying/pasting lines. > > Sincerely, > -- > Neil Watson > 416-673-3465 _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this communication to the intended recipient, or if you have received this communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
