Date: Tue, 10 Dec 2013 01:13:48 +0100 From: "army.of.root" <army.of.root@gmail.com> To: Devin Teske <dteske@freebsd.org> Cc: "freebsd-stable@freebsd.org Stable" <freebsd-stable@freebsd.org> Subject: Re: BIND segway -> python -> first-class ports Message-ID: <52A65CBC.4030503@googlemail.com> In-Reply-To: <F7052902-C640-4AAB-92D5-6A15C6C0A5EE@fisglobal.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> <F7052902-C640-4AAB-92D5-6A15C6C0A5EE@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52A65CBC.4030503>