On Wed, Feb 23, 2005 at 09:15:32AM +0100, Mark Burgess wrote:
> The reason is that "assign value" assumes a particular format of the
> file you are editing. It is not general enough to warrant its own
> function. Perhaps we can think of something else.
Ghm... I don't see why it is not general enough...
let me blurb a bit:
Assignment always has the destination and value -- two components. They
always has to be seaprated with a separator like "spaces","=","-" etc
if I incorporated separator in a definition of a
destination, I do specialization of a "particular format", like
AssignValue "^ *UsePrivilegeSeparation *" To "yes"
for ssh or even fstab configs
AssignValue "^ */dev/sdc1 */raid1 " To "reiserfs defaults,noauto,rw 0 0"
It would even make sense to make "^ *" implicit...
Here I just made myself a problem on what if I want to change
mount_device (/dev/sdc1)... it doesn't fit my scheme, but that is just a
rare exclusion. In most of the configs the destination is always sits on the
left.
Another case to consider I think can be to work with hashed lines line
default ones in sshd configs
So if AssignValue gets prepended with
UnHashAssignValue
it would take and run something like
ReplaceAll "^# *PATTERN_DESTINATION" With "PATTERN_DESTINATION"
where PATTERN_DESTINATION is our "left side"
and then run
AssignValue PATTERN_DESTINATION To VALUE on that string.
So I think it will make many cf configs easier to handle...
Sorry for too many words and may be something was missed from the
beginning ;-)
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers
Office (973) 353-5440 x263 Fax (973) 353-1171
Ph.D. Student CS Dept. NJIT
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
