[augeas-devel] Retrieving last modified node path (Was: First tests with aug mv)

[Raphaël Pinson]

2011/12/17 David Lutterkort <lutter at redhat.com>:
> On Sat, 2011-12-17 at 01:16 +0100, Raphaël Pinson wrote:
>> 2011/12/17 David Lutterkort <lutter at redhat.com>
>> >
>> > On Sat, 2011-12-17 at 00:55 +0100, Raphaël Pinson wrote:
>> > > 2011/12/17 David Lutterkort <lutter at 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