Another tool for updating /etc -- lua||other script language bikeshed

Garrett Cooper yanefbsd at gmail.com
Wed Mar 24 21:52:37 UTC 2010


On Wed, Mar 24, 2010 at 6:11 AM, Ivan Voras <ivoras at freebsd.org> wrote:
> On 03/23/10 16:08, John Baldwin wrote:
>
> [snip - looks like a good utility, will probably use it instead of
> mergemaster if it gets committed, like the idea about automated updates]
>
>> To that end, I wrote a new tool that I think does a decent job of solving
>> these goals.
>
> Since the issue comes around very rarely, I assume there are not many people
> who also get the shivers when they see a shell script (and then a "posixy"
> /bin/sh shell script) more than a 100 lines long? :)
>
> Wouldn't it be nice to have a "blessed" (i.e. present-in-base) script
> language interpreter with a syntax that has evolved since the 1970-ies?
> (with a side-glance to C that *has* evolved since the K&R style).
>
> There was once Perl in base and even though I personally dislike Perl at
> least it was a standard of sorts and guaranteed to be there if needed. Now
> there are some fairly large chunks of code written in plain shell script,
> like mergemaster, freebsd-update, portsup and adduser. I'm not specifically
> against shell scripts but (which might just be my personal opinion) I think
> they are even less maintainable in the long term than Perl scripts. I also
> think the bus factor on good shell script programmers must be pretty low.
>
> As a possible alternative, or at least to learn about others' opinion on the
> subject, I'd like to suggest Lua (http://www.lua.org/).
>
> The reasons:
>
> 1) Very light-weight in terms of system integration. Basically, there are
> one or two executables and libraries and the libraries can be discarded if
> only the interpreter executable is needed and not the ability to integrate
> it into C apps. No "libs directories" needed. Written in C, designed to be
> easy to invoked from C (from which the interpreter executable is built on).
>
> This ability to integrate is important because it allows for some nifty
> things like implementing "system" commands through C, e.g. a "sysctl()"
> function as a wrapper for sysctl(3), or a "GEOM Class" class that wraps
> control of GEOM objects.
>
> The basic interpreter executable and the library are ~~ 150 kB each. The
> /bin/sh executable is 130 kB.
>
> 2) Easy syntax, which even kind of resembles shell scripts in its flow.
> Examples: http://lua-users.org/wiki/SampleCode . Unfortunately, its error
> handling is not much better than plain C (no "exceptions"). It has nice
> C-like formatting (e.g. "%4.2f, %d":format(3.14, 42)) and goodies like
> lexical scoping, foreach and coroutines. It's default OOP implementation is
> a bit specific (the "tables" and "metatables" system) but usable.
>
> 3) MIT license. Friendly.
>
> What would be gained? I guess what I'm trying to suggest is that a 3000 line
> shell script (like portsnap, as a random example) could be more readable,
> easier to write and maintain were it a 3000 line Lua script.

    Code in general becomes a pain to maintain unless it's well
written when it evolves beyond 500 lines (unless it's C / C++, which
is 1000 lines in my book). So, I don't think that changing sh to Lua
would improve anything (in fact it may make things worse because it's
a less mainstream language). There are a host of other languages out
there that could also serve the needs of the infrastructure, but the
fact remains that the more divergence the project goes in terms of
defacto standard languages, the more of a pain in the ass it's going
to be to maintain longterm because someone decided to write something
in language X.Y.Z.
    And there are actually some things which could be done to simplify
the mergemaster and portsnap scripts as well (minor bloat?), but I
digress.
Thanks,
-Garrett


More information about the freebsd-hackers mailing list