Date: Mon, 9 Dec 2013 17:27:35 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: George Mitchell <george+freebsd@m5p.com> Cc: Devin Teske <dteske@freebsd.org>, "freebsd-stable@freebsd.org Stable" <freebsd-stable@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: BIND segway -> python -> first-class ports Message-ID: <F7052902-C640-4AAB-92D5-6A15C6C0A5EE@fisglobal.com> In-Reply-To: <52A5A7D4.4080404@m5p.com> References: <mailman.313.1386119137.1390.freebsd-stable@freebsd.org> <529E8C53.6020208@freebsd.org> <Pine.GSO.4.64.1312032238220.15897@sea.ntplx.net> <20131204060246.GV2951@home.opsec.eu> <CAN6yY1udd1GbQVK4YR-yxNe7vqX3S1refQwch2cafRnMv=W4mA@mail.gmail.com> <CAFHbX1K1AgZ4FaEjP_vvnfiwDWsj6M3ysEVn4taX_4_p%2B1Z8Nw@mail.gmail.com> <CAN6yY1tjS=uk1Qr-sBN0PT73xpP%2BBxL8wLt9aosYfWf751rC5A@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F7052902-C640-4AAB-92D5-6A15C6C0A5EE>