[augeas-devel] [PATCH] php lens

[David Lutterkort]

On Tue, 2008-04-22 at 17:01 -0400, Bryan Kearney wrote:
> Attached is a patch to add a php lens. Couple of notes:
> 
> 1) This is pretty much a copy of yum except for the line
> 
> let value = /[^\n]*(\n[ \t]+[^ \t\n]+)*/
> 
> In yum it is
> 
> let value = /[^ \t][^\n]*(\n[ \t]+[^ \t\n]+)*/
> 
> This was becuase the default php.ini has many blank items
> foo=
> 
> where the yum pattern added a newline.

The yum pattern is fairly complicated because yum allows 'continuation
lines', as in

        baseurl=http://server1/path
          http://server2/path
        
i.e., you can split one logical value across multiple lines (I want to
fix that so that you get multiple baseurl entries in the tree instead of
one with a string you need to split yourself).

It seems that php.ini is a little simpler and that values simply extend
to the end of the line, so that
   let value = /[^\n]*/
should work 

> 2) I can not get the test to work. If I run augtest, it fails. If I run 
> augtest ini-php.change.rb I get the following
> 
> [bkearney at localhost tests]$ augtest ini-php-change.rb
> ./../lenses/php.aug:13.2-.50:Failed to compile kv
> syntax.c:1846 Fixme: Cleanup loaded modules
> Failed to initialize Augeas
> Test ini-php-change ... FAIL
> Expected file ./../build/augtest/etc/php.ini.augnew
> 
> 
> If I run it manually, it works. Any help on how to solve the testing, I 
> will go change it.

Are you sure ? For me, augparse refuses to load the file:

        galia:[10138] augeas>augparse -I lenses/ lenses/php.aug 
        lenses/php.aug:13.2-.50:Failed to compile kv
        lenses/php.aug:13.13-.42:exception: ambiguous concatenation
              'A: ' can be split into
              'A:|=| '
        
             and
              'A: |=|'
        
            First lens: lenses/php.aug:13.13-.28
            Second lens: lenses/php.aug:13.31-.42
        
        lenses/php.aug: error: Loading failed
        
When developing new lenses/schema, it is best to write a lenses/foo.aug
side by side with unit tests in lenses/tests/test_foo.aug (using Augeas'
builtin testing, not augtest) and running

        augparse -I lenses lenses/tests/test_foo.aug
        
augparse will give you much better error messages than augtool (and does
more checking, by default, since some checks are pretty expensive).
Writing those tests[1] makes it easier to 'bootstrap' lenses, since you
can start with tests on very simple data (or test lenses other than the
'main' lens) and see exactly the tree that Augeas generates.

The error above complains that the concatenation of 'key key_re .
eq' (the first lens, the "13.13-.28" means "line 13 from columns 13 to
28') and 'store value' (the second lens) is ambiguous and gives you an
example: a line like "A: " can either be parsed in two ways:
     1. as "A:" matching the first lens and " " matching the second lens
        (the '|=|' is a separator Augeas uses to indicate positions in
        strings)
     2. as "A: " matching the first lens and "" matching the second lens
IOW, it doesn't know whether to take a space after a colon and treat is
as part of the 'eq', in which case it is omitted from the tree, or match
it as part of the 'store value', in which case the space shows up in the
tree.

Augeas is a bit of a stickler for such details, but as this example
shows, that is necessary to make sure the right action is taken on
matches.

If I change value to /(()|[^ \t\n][^\n]*)/, augparse at least is happy.
I couldn't run your test since I don't have your php.ini to run it
against ;) That regexp says 'a value is either the empty word[2], or a
nonspace character followed by any number of non-newline characters[3]'

David

[1] http://augeas.net/docs/writing-schemas.html
[2] You need to use '()' in a regexp for the empty string, because of a 
    bug in my regexp parser (in fa.c) - POSIX allows stuff like '(|a)' 
    to match the empty string or an 'a', but my regexp parser gets 
    confused and sees that as "a literal '|' followed by an 'a'" - something
    I need to fix; in the meantime, you have to write '(()|a)' in such
    constructs.
[3] In yet another deviation from POSIX, you can write /[^\n]/ as /./, i.e.,
    the dot does not match newlines; that one is intentional and I actually
    think of it as a feature ;) You can therefore write the new regexp for 
    value above as /(()|[^ \t\n].*)/