WIP: Lua interpreter in augtool

[raphink]

This PR adds a -l/--lua flag to augtool which allows to code in Lua instead of the native augrun interpreter.

Examples can be found in tests/test.auglua.

Current shortcomings:

• Not all calls are implemented (but do we need them all?)
• Multiline expressions do not workin the REPL (unfinished lines should change the prompt)
• History does not work in the REPL
• Must call aug_close and lua_close somewhere
• quit is not recognized in Lua mode, but ^D works
• No tests for error checking
• Missing autocompletion in Lua mode
• It might be good to put most of it into a auglua.c file for a cleaner augtool.c
• Do we want to expose this in the Augeas API, or only in Augtool?
• Do we want to call all functions aug_* or simply * (such as set, get, etc.) so they behave like the augrun interface? So far, I'm doing both... I'm actually declaring a global table aug and assigning all functions to it now
• arg commands do not honor the lua flag
• pass arguments to lua scripts
• autosave does not work with lua ("save" is passed, but "aug.save()" is the way to do it)

Example script that reimplements augeasproviders_shellvar in lua: https://gist.github.com/raphink/4fcb67ae9b56675e76a8

@lutter @domcleal what's your take on this?

[raphink]

I kind of fixed the multiline lua REPL problem, irb-style. The implementation might not be perfect, but it works:

augtool|lua> for k, v in pairs(match("etc/passwd/*")) do
augtool|lua?>   print(get(v .. "/uid"))
augtool|lua?>   end
0
1
2
3
4
5
6
7
8
10
11
12
13
14
99
69
32
29
4294967294
augtool|lua> 

[raphink]

@ncopa since you wrote the bindings for lua, do you have an opinion on this?

[ncopa]

what is the benefit with embedding lua into augeas instead of just using lua-augeas module?

[raphink]

@ncopa most users (at least sysadmins) will not want to install a lua interpreter (if they know it exists), the lua bindings for Augeas, and write a script that sets up a handler (if they know how that works), but they need to be able to perform operations and loop in the code they use in augtool

The idea here is that you can simply install augeas-tools, launch augtool -l and you have an already set up aug library, and you can use the augtool flags to control the fake root, lens lib dir, etc.

The typical use I'm thinking of is setting up docker containers using augtool-based scripts.

[lutter]

I really like the idea of having some sort of standard scripting language readily available when you install augeas - and lua seems to be a great fit for that. This is awesome stuff.

I am not 100% sold on whether that should be part of augtool or a separate tool - I need to understand the tradeoffs better in terms of platform suppport, addl dependencies, and (maybe) size. I am not against it, just that I need a clearer picture of these things.

Also: if we ship with lua support by default, wouldn't we also want some sort of basic lua scripts/libraries, i.e. the ability to ship conveniences in lua, basically things that either make working with the augeas API easier from lua, or that give you canned answers for common tasks ? That doesn't have to happen right off the bat, but is something to keep in mind as this evolves.

[raphink]

Thanks for reviewing @lutter.

From what I can see, Lua supports at least as many platforms as we do (Unix + Windows). It is known for being not only embeddable, but also very light. I've tried building Augeas statically to compare, but there is a local definition of xasprintf which conflicts when building statically.

As for external Lua libraries, I believe you should be able to use require 'somelib' in augtool with the current code.

[raphink]

I commented out the definition of xasprintf in augtool.c and managed to build statically (or so it seems). So here are the sizes of the augtool binary:

• without lua support: 1584769
• with lua support: 1618371

So Lua support adds 33602 (32K) to the static binary.

[igalic]

has there been no release since your patch?
i.e.: shouldn't this be 0.21.0?

[raphink]

You're right, that was a testing thing. I guess this entry also depends on whether we expose aug_lua

[ncopa]

I would like to merge the majority of this with https://github.com/ncopa/lua-augeas/blob/master/laugeas.c into a common C file. Then we could have a separate make target for a lua module, so we could build the lua-augeas directly from the augeas sources, in addition to the lua embedded stuff.

[raphink]

@ncopa which parts exactly would you like to merge into lua-augeas?

[raphink]

Rebased on master

[kunkku]

@raphink I understand ncopa's comment such that there is a considerable overlap between your auglua.c and his laugeas.c. He would like to abolish his lua-augeas project and build the Lua bindings from the Augeas source tree in future.

[raphink]

I understand that... I don't have much time for that (or extended knowledge of Lua), but I have several projects that would benefit from lua integration in augtool...

[raphink]

@ncopa do you have some time maybe to help me implement that properly?

[raphink]

@kunkku there is already a lua-augeas project, but the goal here is really to embed lua in augtool.

[raphink]

@kunkku just added commits to this PR (thank you).

[lutter]

I've recently started playing with mruby and really like it. I ported the ruby bindings over to it

All of this makes me wonder if an mruby-based command line tool might not be a better option, as it seems a lot more people are familiar with that than with Lua. To give you some impression of what that looks like, this is an example of using mruby with augeas

[raphink]

I've seen lua in a lot of projects, but never mruby, so i can't really tell. I guess all that matters would be to bring higher level language into augeas itself.