From owner-freebsd-stable@FreeBSD.ORG Mon Dec 9 17:27:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82A7F68C; Mon, 9 Dec 2013 17:27:38 +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 404021E74; Mon, 9 Dec 2013 17:27:37 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id rB9HRZcs001917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Dec 2013 11:27:35 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 11:27:35 -0600 From: "Teske, Devin" To: George Mitchell Subject: Re: BIND segway -> python -> first-class ports Thread-Topic: BIND segway -> python -> first-class ports Thread-Index: AQHO9EPVAMsIQg72sUSzcf93F1B7uw== Date: Mon, 9 Dec 2013 17:27:35 +0000 Message-ID: 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: <52A5A7D4.4080404@m5p.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: <4171F47CBF52C5439FD9710FB650E62F@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_01: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: Mon, 09 Dec 2013 17:27:38 -0000 On Dec 9, 2013, at 3:21 AM, George Mitchell wrote: > 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 s= upreme >> 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 trying >> building libraries used to abstract higher functionality for cross-platf= orm >> compatibility. And, until now, that's primarily been in C -- shell is on= ly a >> recent excursion because I feel I've *finally* nailed the right recipes = for >> that. >>=20 >> I'm actually a bit worried that Python and Lua don't have the reach that= 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 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 yea= r 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 libfi= gpar. 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 li= bfigpar 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 she= ll. 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 t= hat 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 environm= ents 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 t= hings for base... I'm curious to know if this could fit your need. --=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.