[augeas-devel] Non-empty string from get has turned into empty node for put direction - why?

[David Lutterkort]

On Mon, Dec 21, 2015 at 3:51 AM, Mol, Xavier (SCC) <xavier.mol at kit.edu>
wrote:

> I have altered Quote.dquote_spaces such that '#' in unquoted values are no
> longer accepted and the final statement looks like this:
>
>
>
> [ lns . (bare|quoted) ]
>
>
>
> To me that is identical to what the Quote module states:
>
>
>
> [ lns . bare ]|[ lns . quoted ]
>
>
>
> But augtool disagrees. Can you maybe explain the difference (in put
> direction) here?
>

Yes, the difference is unfortunately terribly subtle: the first form says
'create a node in the tree from text matching "lns . (bare|quoted)"'. When
the time comes to write a tree back to disk, we recognize that we are
looking at such a node by comparing the node's key* with whatever key or
label statements are inside the "[ ... ]" and then use "lns .
(bare|quoted)" to write out that node and its children.

The second form says 'create one of two possible nodes, depending on
whether the text matches "lns . bare" or "lns .quoted"'. When we want to
write out a tree with such a node, we first check whether that node matches
"lns . bare" or "lns . quoted" and then proceed accordingly. To make that
decision, the two constructs "[lns . bare]" and "[lns . quoted]" must match
different kinds of tree nodes, i.e. it must be possible to make that
decision from just looking at the key* of such a tree node. I assume that
only "lns" in your example sets the key of a tree node; that means that
Augeas can't determine whether it should use the first or the second "[ ...
]" in the overall construct. That's what it is complaining about with the
error 'overlapping lenses in tree union.put': there's a construct "[ l1 ] |
[ l2 ]", and at least for some tree nodes, both "[ l1 ]" and "[ l2 ]" would
match so that Augeas can't tell which of these two to use.

I'd love to have a better error message for this situation (without the
wall of text above ;)

David

*: Augeas actually doesn't just look at the keys of tree nodes, but also at
their values to determine whether a tree node matches a lens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20160222/66674015/attachment.htm>