2011/12/17 David Lutterkort <lut...@redhat.com>: > On Sat, 2011-12-17 at 01:16 +0100, Raphaël Pinson wrote: >> 2011/12/17 David Lutterkort <lut...@redhat.com> >> > >> > On Sat, 2011-12-17 at 00:55 +0100, Raphaël Pinson wrote: >> > > 2011/12/17 David Lutterkort <lut...@redhat.com> >> > > >> > > > On Fri, 2011-12-16 at 14:01 +0100, Raphaël Pinson wrote: >> > > > > Resurrecting this old thread... >> > > > > >> > > > > We now have more calls that have the same issue as rm, namely setm >> > > > > and >> > > > > clearm, which modify more than one node. >> > > > > >> > > > > How could be adapt the idea to this? Maybe having several nodes under >> > > > > /augeas/tree/last_created and/or /augeas/tree/last_modified ? >> > > > >> > > > I would follow the model set by save and create entries >> > > > underneath /augeas/events, >> > > > e.g. /augeas/events/removed, /augeas/events/inserted etc. >> > > > >> > > > Right now, /augeas/events doesn't get cleared out in api_entry, but we >> > > > might consider doing that - or should we leave that to the user ? They >> > > > could then issue three 'rm' and just collect all the removed nodes. >> > > > >> > > >> > > >> > > If they get stacked in order, why not. aug_rm returns the number of nodes >> > > that were removed, so you know how many nodes you have to take out of the >> > > pile. >> > > >> > > So we could have something like: >> > > >> > > /augeas/events/removed[1] >> > > /augeas/events/inserted[1] >> > > /augeas/events/modified[1] >> > > /augeas/events/modified[2] >> > > /augeas/events/inserted[3] >> > > /augeas/events/removed[2] >> > > /augeas/events/removed[3] >> > > >> > > etc. where the last aug_rm call removed 2 nodes (and thus returned 2). >> > > You >> > > would then have to depile /augeas/events/removed[last()] and >> > > /augeas/events/removed[last()-1] to get their paths. >> > > >> > > Is that what you mean? >> > >> > After doing something like >> > rm /foo/bar >> > set /foo/bar 3 >> > ins bar before /foo/bar >> > set /foo/bar[1] 2 >> > >> > you'd have something like >> > >> > /augeas/events/removed "/foo/bar" >> > /augeas/events/created "/foo/bar" >> > /augeas/events/inserted "/foo/bar[1]" >> > /augeas/events/modified "/foo/bar[1]" >> > >> > How do you plan on using this info ? >> > >> >> >> Well, say you want to insert a node after a given node, and then use >> it. This is currently quite hard to do, but can be achieved with: >> >> defvar mynode /files/path/to/file/somenode >> ins somelabel after $mynode >> defvar newnode >> /files/path/to/file/somelabel[preceding-sibling::*[1][$mynode]] >> set $newnode somevalue >> >> >> Using /augeas/events could make this clearer as you could do: >> >> aug_insert(aug, "/files/path/to/file/somenode", "somelabel", "after"); >> newnode = aug_get(aug, "/augeas/events/inserted[last()]"); >> aug_set(aug, newnode, "somevalue"); > > Yes, definitely less of a head-scratcher; to make this doable in > augtool, we need a way to interpret the value of a node as a path > expression. > > Maybe a function nodes in the path expression language so that you can > say > > ins somelabel after /files/path/to/file/somenode > set nodes(/augeas/events/inserted[last()]) "somevalue" > > IOW, nodes would be a function that takes a string (the value > of /augeas/events/inserted[last()]) and returns a nodeset.
This is definitely needed (for other applications, too). I think maybe a value() function would be clearer. It would take a node and return its value (if any). Now I understand that this might be a problem as far as casting the type for commands, so maybe it should have two commands? set /files/path/to/file/node1 value(/files/path/to/file/node2) which would actually implement a cp command of a sort set nodes(/augeas/events/inserted[last()]) "somevalue" unless it could be done using value() instead of nodes() without generating typing issues? Raphaël _______________________________________________ augeas-devel mailing list augeas-devel@redhat.com https://www.redhat.com/mailman/listinfo/augeas-devel
