[augeas-devel] Default label for a node in a path expression

[Raphaël Pinson]

On Tue, Jan 7, 2014 at 7:52 AM, Raphaël Pinson <
raphael.pinson at camptocamp.com> wrote:

> Hi David,
>
>
> On Mon, Jan 6, 2014 at 11:04 PM, David Lutterkort <lutter at watzmann.net>wrote:
>>
>>  There's regularly people asking how to write idempotent set expressions.
>>> With labeled nodes, we have the usual trick:
>>>
>>>     set foo[.='bar'] 'bar'
>>>
>>> which creates the 'foo' node with the 'bar' value if it doesn't exist.
>>>
>>
>> Yes, I agree with both - that it's not wel supported right now, and that
>> it is needed. The underlying problem is that there's no good way to infer
>> from a path expression where the newly created node  should go in case the
>> path expression doesn't match.
>>
>> Rather than put something in the XPath language, I think it would be
>> cleaner to do this explicitly in a dedicated command. I can think of a few
>> ways to do that. The simplest would be a aug_set_or_create(expr, path,
>> value) that goes something like this:
>>
>> if aug_match(expr) == 1
>>   aug_set(expr, value)
>> elsif aug_match(expr) == 0
>>   aug_set(path, value)
>> else
>>   complain
>> end
>>
>> Here, EXPR is an XPath expression, and PATH is a literal path that has
>> enough information to create nodes from unambiguously. Maybe we'd need to
>> also allow a BASE (XPath expression) so that not all of PATH needs to be
>> fixed, and both EXPR and PATH would be relative to that.
>>
>>
> That looks good and simple enough. However, it means we'll have to create
> a new call for all the calls for this kind: set, setm, clear, clearm,
> defnode, maybe even a way to make insert more idempotent with these paths.
>
>
>
>> But thinking of a scenario where you want to create an entry in
>> /etc/hosts if it's not there, that might still not be enough, and we might
>> ultimately need to introduce an 'if' statement into the language that
>> aug_srun accepts - though that has all kinds of ripple effects as you now
>> also need to define expressions for that if statement ...
>>
>
>
> Right. One option that was mentioned on IRC yesterday would be to use an
> embedded language to add this logic, to avoid implementing yet another
> interpreter. Lua obviously comes to mind. We could then have an aug_lua
> call, which would supersede aug_srun and take Lua commands as input. Lua
> would then call the C methods to control Augeas. aug_lua would
> automatically get a pre-set Augeas handler with the options passed to the C
> lib.
>
> Eventually, augtool could have a --lua|-l option which would make it use
> aug_lua instead of aug_srun as the interpreter:
>
>     #!/usr/bin/augtool -lsf
>     if augeas.match('/files/path/to/some/node') == 0
>       augeas.set('/some/path', 'value')
>     elsif …
>        augeas.insert('label', 'path', 'before')
>     end
>
>
>
>>
>> So I've thought maybe we could add to the XPath language:
>>>
>>>     set /path/to/*[default() = "foo"][. = "bar"] "bar"
>>>
>>> If no node matching /path/to/* is found, then a new node would be
>>> created using label "foo". This would allow for multiple level defaults,
>>> such as:
>>>
>>>     set /path/to/*[default() = "foo"][. = "bar"]/*[default = "foz"][. =
>>> "baz"] "baz"
>>>
>>> and defaults would be applied at each level. I don't know about the
>>> feasability of this, but it would bring the most flexibility and it would
>>> allow to easily write idempotent set commands for seq nodes, too:
>>>
>>>     set /path/to/*[default() = "01"][. = "bar"] "bar"
>>>
>>
>> I think that's an elegant approach, though I am not sure how
>> understandable this would be to users. At the very least, I'd use a
>> different syntax than the '[ ... ]' predicates (right now '=' means
>> comparison, not assignment), something like
>>
>> set /path/to/*<01>[. = "bar"]
>>
>> That will lead to headaches in parse_name in pathx.c, since we will then
>> disallow '{' in file names. Maybe
>>
>> set /path/to/*[<01> . = "bar"]
>>
>> would reduce the need to restrict what characters we like in file names
>> ...
>>
>>
> I'm not sure if this would be very natural to write though.
>
>
How about setting the default label after the conditions, such as:

   set /path/to/*[. = "bar"]<01>

This wouldn't prevent "<>" in file names, would it?


-- 
Raphaël Pinson
Infrastructure Developer & Trainer
+33 479 26 57 93
+33 781 90 00 79

Camptocamp France
Savoie Technolac
BP 352
48, avenue du Lac du Bourget
73372 Le Bourget du Lac, Cedex
www.camptocamp.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20140107/d25dd9e6/attachment.htm>