From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 24 21:52:37 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEAC8106566C for ; Wed, 24 Mar 2010 21:52:37 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pz0-f196.google.com (mail-pz0-f196.google.com [209.85.222.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4F18FC0C for ; Wed, 24 Mar 2010 21:52:37 +0000 (UTC) Received: by pzk34 with SMTP id 34so1247573pzk.3 for ; Wed, 24 Mar 2010 14:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=u2j+iqq+dcI7230rXBxt0z6A4jUhSRsoArD0S8QjruY=; b=eZ7bqFQzv1DlWLdtwlBanBHRP6qsGx0Jon/eaB5yGNO94RbEROhNihjzrkoetCjY9o ZGHT7DOwkm5AugdRyBTSCijU0OXhRwVHGSn2J7j0fhAE3yzF/HyQbh82nXsdHpckAGYF Ms6FABpZq+kWDhMqu/Zh63WMBwbymA/apSRBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=axta+UUxUGQCQCWtFMkUNa9liNwp3QFAcJZANzNz4kIlvQmfUfZTTpsnluCeeiwD+S agu/NIwPDfrnRnAr81ehTWlZeBvW45ySfk6R0Mw8N6InjUO0rxrFYgY/Fy4HKMPFGS6l 2kd49dx9HTNfNt5aS9ScbK1QT8iTgZe9rrTP4= MIME-Version: 1.0 Received: by 10.141.53.5 with SMTP id f5mr6004425rvk.178.1269467556901; Wed, 24 Mar 2010 14:52:36 -0700 (PDT) In-Reply-To: References: <201003231108.45102.jhb@freebsd.org> Date: Wed, 24 Mar 2010 14:52:36 -0700 Message-ID: <7d6fde3d1003241452j2cfebea7r108aab0579b13938@mail.gmail.com> From: Garrett Cooper To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Another tool for updating /etc -- lua||other script language bikeshed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:52:37 -0000 On Wed, Mar 24, 2010 at 6:11 AM, Ivan Voras 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