From owner-freebsd-stable@FreeBSD.ORG Tue Dec 10 00:59:10 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 7E103A92; Tue, 10 Dec 2013 00:59:10 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3AD6C115C; Tue, 10 Dec 2013 00:59:09 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id rBA0x2h8002834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Dec 2013 18:59:02 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:59:01 -0600 From: "Teske, Devin" To: "army.of.root" Subject: Re: BIND segway -> python -> first-class ports Thread-Topic: BIND segway -> python -> first-class ports Thread-Index: AQHO9EPVAMsIQg72sUSzcf93F1B7uw== Date: Tue, 10 Dec 2013 00:59:00 +0000 Message-ID: <66114E14-6B6A-461B-8F35-D821A8A56C80@fisglobal.com> 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> <52A65CBC.4030503@googlemail.com> In-Reply-To: <52A65CBC.4030503@googlemail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <7CE92AAD5AAB2F47805D257FEB7D9C7B@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-12-09_03:2013-12-09,2013-12-09,1970-01-01 signatures=0 Cc: Devin Teske , "freebsd-stable@freebsd.org Stable" , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske 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:59:10 -0000 On Dec 9, 2013, at 4:13 PM, army.of.root wrote: > Am 09/12/13 18:27, schrieb Teske, Devin: >>=20 >> On Dec 9, 2013, at 3:21 AM, George Mitchell wrote: >>=20 >>> On 12/09/13 00:39, Teske, Devin wrote: >>>> [...] >>>> But keep in mind... >>>>=20 >>>> 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: >>>>=20 >>>> + 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. >>>>=20 >>>> All with a single source package. It's the power of POSIX. >>>>=20 >>>> 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". >>>>=20 >>>> Shell quite often doesn't cut it. Prior to shell, I spent my time tryi= ng >>>> building libraries used to abstract higher functionality for cross-pla= tform >>>> 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 recipe= s for >>>> that. >>>>=20 >>>> I'm actually a bit worried that Python and Lua don't have the reach th= at C does, >>>> let alone shell. >>>>=20 >>>=20 >>> +1 to a well-reasoned and insightful post. >>>=20 >>> 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 >>=20 >> Hi George, >>=20 >> I'm glad you asked. Because this is actually something that I've been >> evaluating since (gosh) 2001. >>=20 >> 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 sou= rce >> software so I had a backup (somewhat). Unfortunately, his version was ol= d, >> 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). >>=20 >> I introduce to you ... libfigpar... >>=20 >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/libfigpar/ >>=20 >> ASIDE: The name figpar stands for "con[fig]uration [par]ser". >>=20 >> You can see it in action here... >>=20 >> 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 >>=20 >> And I have plans to write a "jailconf" that reads /etc/jail.conf with li= bfigpar. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 ma= ke the C >> code fork-exec to sh(1) several times considering rc.conf(5) is in-fact = shell. >>=20 >> So you asked about the possibility of a Grand Unified Schema, and this i= s my >> take. The library brings the parsing, but you have to bring the function= s that >> handle the values. When you invoke the parser, you give it a few things.= .. >>=20 >> + A bit-field of options that can change the way it parses (strict v loo= se, etc.) >> + A series of function pointers for handling specific data types. >>=20 >> (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) >>=20 >> But... alas... >>=20 >> 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,e= tc.}. >>=20 >> But that's the easy part. Resurrecting the core processing module (stayi= ng true >> to the fact that original was compiling on over 40 different POSIX envir= onments >> and working perfectly) -- that was the hard part. >>=20 >> 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. >>=20 >> But of course... I'd love feedback as ... being how I am developing thos= e things >> for base... I'm curious to know if this could fit your need. >>=20 >=20 > Reading this, I remembered http://augeas.net/ which I stumbled over readi= ng up on ovirt. >=20 > I like proper formats better than some magic middleware though. (givng yo= u schemas incl. validation, xquery style access, standard tooling etc.) >=20 > Could even be done via "proxies" which are completely specified XML schem= as with round trip conversion. Maybe even portable supersets. Hey, that looks really nice. I'm going to have to sit down and play with th= at. Wonder what the licensing is. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.