Hi David,
This is really neat! I've just applied the series and tested a bit. First, I think it could be nice to have completion in augtool on lens names ; Then, when using retrieve, there's a few things I noticed: * It could be interesting to store the association information somewhere, in the way it is done for file -> tree transformations. This way, the <LENS> parameter would be optional and Augeas would automatically guess it ; * the <TEXT> parameter is a bit confusing at first. I understood you have to pass a string (any string actually) that is valid for the given lens, say: augtool> retrieve Hosts.comment /my/comment "# a\n" I'm wondering if, again, this could be optional... Idealy, I think retrieve could take one mandatory parameter and 2 optional ones. Raphaël On Tue, May 22, 2012 at 2:44 AM, <[email protected]> wrote: > > A while ago, Rich Jones asked on IRC if would be possible to add API calls > so that strings can directly be transformed and stored in the tree through > the API. This patch series implements calls to do that. > > The two new API functions aug_text_store and aug_text_retrieve can be used > to produce a tree from a string, respectively a string from a tree. > > The prototypes for these functions are > > int aug_text_store(augeas *aug, const char *lens, const char *path, > const char *text, unsigned int text_len); > int aug_text_retrieve(struct augeas *aug, const char *lens, const char > *path, > const char *text_in, unsigned int text_in_len, > char **text_out, unsigned int *text_out_len); > > While playing with these, I noticed that it would be much nicer for > retrieve if we stored the raw input string somewhere in the tree. I am > contemplating to change the above so that the input/output strings are > taken from the values of nodes in the tree. That would mean that in augtool > you'd do > > set /raw/in/t1 "192.168.0.1 host.example.com machine\n" > store Hosts.lns /raw/in/t1 /text/t1 > .. change /text/t1 ... > retrieve Hosts.lns /raw/in/t1 /text/t1 /raw/out/t1 > get /raw/out/t1 > > I think this latter form is nicer, but I'd like to hear from others what > they think. > > There are currently no restrictions on which tree nodes > aug_text_store/aug_text_retrieve operate - I think that's actually an > advantage, and I think it should stay that way. Parse errors for storeing > into PATH are stored under /augeas/text/PATH (with the consequence that > parse errors for storing at /text/t1 go into /augeas/text/text/t1) > > Comments, complaints, and reviews very welcome. > > David > > _______________________________________________ > augeas-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/augeas-devel >
_______________________________________________ augeas-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/augeas-devel
