From owner-freebsd-stable@FreeBSD.ORG Tue Dec 10 00:13:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13F9395; Tue, 10 Dec 2013 00:13:55 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CB8E1E96; Tue, 10 Dec 2013 00:13:54 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id b57so1874066eek.31 for ; Mon, 09 Dec 2013 16:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HsBrglJM/Z9tjpjmecRZAzM/LSngtmVT676aDf2gUtg=; b=tds3OxiO6zGTCou5BF3H/V9dJ0g82+ZrjaIksT3p6KGagVaACPgpJ8jhlEiv0UhNB+ FkRg9IPvABQTjUDpP7/FvDzVQ1tQuARrEajHKotC9O9ef7W8983lUY840tRQMTjgViI1 vLbbq2w5sE2ItRwjri9RZYUdKDn3paunsYQaXuL25UaP8yhMdaWBlZG6BmfhS/7WvMXU j5s4jbREX9UzIGltDiorg3TpBt3HPw8lgIbOw3cOZD9ZuGxv5AVUGiLFVLSPjwldnOZv Gx0f4fUirNKA22lxNIwdAPTJkMOlj7bNsZdKds+Ji0hHKHbbMScjs5jktlMgqIGnZXUk wnqg== X-Received: by 10.15.56.7 with SMTP id x7mr14803391eew.43.1386634432535; Mon, 09 Dec 2013 16:13:52 -0800 (PST) Received: from macbook-pro.local (ip-176-199-25-222.unitymediagroup.de. [176.199.25.222]) by mx.google.com with ESMTPSA id n1sm34573560eep.20.2013.12.09.16.13.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 16:13:51 -0800 (PST) Message-ID: <52A65CBC.4030503@googlemail.com> Date: Tue, 10 Dec 2013 01:13:48 +0100 From: "army.of.root" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Devin Teske Subject: Re: BIND segway -> python -> first-class ports References: <529E8C53.6020208@freebsd.org> <20131204060246.GV2951@home.opsec.eu> <52A12843.3010204@freebsd.org> <0BFC927B-D72E-4926-BB3D-2C000F310BDD@fisglobal.com> <7271C4C4-7BAB-4DA7-9E10-49D5B2DB8964@mu.org> <52A51438.4090200@bluerosetech.com> <8D54491D-5A1C-4D30-AD48-12336D0726DC@gsoft.com.au> <5C28ECE3-CE0C-44A9-A7CD-08A01C714594@fisglobal.com> <52A5A7D4.4080404@m5p.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:13:55 -0000 Am 09/12/13 18:27, schrieb Teske, Devin: > > On Dec 9, 2013, at 3:21 AM, George Mitchell wrote: > >> On 12/09/13 00:39, Teske, Devin wrote: >>> [...] >>> But keep in mind... >>> >>> The real power is not in shell, the real power is in POSIX. I have the supreme >>> pleasure of having developed C programs that can compile on: >>> >>> + Windows using MinGW >>> + Mac OS X using ... gcc >>> + Mac OS Classic using SIOUX >>> NB: Simple Input/Output User eXchange >>> + Linux, Unix, BSD, AIX, OSF1, Amiga, etc. >>> >>> All with a single source package. It's the power of POSIX. >>> >>> So whenever I've made a choice to target "/bin/sh" as a platform, it's >>> always *only* ever been based on the decision of "reach". >>> >>> Shell quite often doesn't cut it. Prior to shell, I spent my time trying >>> building libraries used to abstract higher functionality for cross-platform >>> compatibility. And, until now, that's primarily been in C -- shell is only a >>> recent excursion because I feel I've *finally* nailed the right recipes for >>> that. >>> >>> I'm actually a bit worried that Python and Lua don't have the reach that C does, >>> let alone shell. >>> >> >> +1 to a well-reasoned and insightful post. >> >> What are your thoughts on the other part of Mr. Perlstein's concern: the >> lack of what I would like to call a Grand Unified Schema? Perhaps such >> a thing belongs in POSIX as well, as it would be intriguing to be able >> to write tools (in whatever language) that could rely on uniformly >> parseable data (i.e. sizes always known to be in eight-bit bytes, text >> in UTF-8 [let's say], time in seconds, numbers in decimal without >> commas, key-value pairs in a specified format, consistent meaning for >> key names). -- George > > Hi George, > > I'm glad you asked. Because this is actually something that I've been > evaluating since (gosh) 2001. > > NB: In 2002 I was a victim of a burglary and lost the original version of > this solution. Thank God, a buddy in France was using it in his open source > software so I had a backup (somewhat). Unfortunately, his version was old, > but at least it was enough to reconstruct in 2013 (it wasn't until this year that > I had excellent reason to bug my buddy kang to go digging for it). > > I introduce to you ... libfigpar... > > http://druidbsd.cvs.sf.net/viewvc/druidbsd/libfigpar/ > > ASIDE: The name figpar stands for "con[fig]uration [par]ser". > > You can see it in action here... > > http://druidbsd.cvs.sf.net/viewvc/druidbsd/sysconf/ > -- reads loader.conf(5) and sysctl.conf(5) using libfigpar > http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/ > -- reads ~/.dialogrc using libfigpar > > And I have plans to write a "jailconf" that reads /etc/jail.conf with libfigpar. > > I'm aware that sysctl(8) has it's own C code for parsing sysctl.conf. > I'm also aware that jail(8) has it's own C code for parsing jail.conf. > > However, libfigpar allows all these to be parsed with a single library. > Making things accessible to other languages besides C/C++, you can > see by sysconf(8) above that the analogous FFI can be built. > > NB: I still am wrestling with the idea of rewriting sysrc(8) in C to use libfigpar > but... the only thing stopping me is that I know that I would have to make the C > code fork-exec to sh(1) several times considering rc.conf(5) is in-fact shell. > > So you asked about the possibility of a Grand Unified Schema, and this is my > take. The library brings the parsing, but you have to bring the functions that > handle the values. When you invoke the parser, you give it a few things... > > + A bit-field of options that can change the way it parses (strict v loose, etc.) > + A series of function pointers for handling specific data types. > > (and I'm sure I'm forgetting much... I wrote a man-page in the CVS repo so I > wouldn't have to memorize everything) > > But... alas... > > One of the things that I lost (which is not that hard to get back) from the original > version was the defacto processing functions set{str,strarray,num,bool,etc.}. > > But that's the easy part. Resurrecting the core processing module (staying true > to the fact that original was compiling on over 40 different POSIX environments > and working perfectly) -- that was the hard part. > > As you can see from my works-in-progress... sysconf(8) and fdpv(1) ... I'm having > loads of fun with libfigpar ;D makes parsing easy and stores the data in a really > nice memory format for simple access. > > But of course... I'd love feedback as ... being how I am developing those things > for base... I'm curious to know if this could fit your need. > Reading this, I remembered http://augeas.net/ which I stumbled over reading up on ovirt. I like proper formats better than some magic middleware though. (givng you schemas incl. validation, xquery style access, standard tooling etc.) Could even be done via "proxies" which are completely specified XML schemas with round trip conversion. Maybe even portable supersets.