Date: Wed, 24 Mar 2010 14:11:21 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: Another tool for updating /etc -- lua||other script language bikeshed Message-ID: <hod31p$qlc$1@dough.gmane.org> In-Reply-To: <201003231108.45102.jhb@freebsd.org> References: <201003231108.45102.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Thoughts?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hod31p$qlc$1>