On Fri, Mar 20, 2009 at 01:37:27AM +0200, George Danchev wrote:
> On Thursday 19 March 2009 23:12:22 Peter Pentchev wrote:
[snip]
> > The reason I cross-referenced it in the SEE ALSO section of the confget(1)
> > manual page is not to describe the format, but to point to a different
> > implementation, a different programming library that people can use to
> > access INI files. Maybe it's not quite clear, and I agree that maybe,
> > once in a while, it could even be confuzzling; do you think I should drop
> > the cross-reference and just spell it out in words, something like
> > "Another INI parser is the Config::IniFiles Perl module" or something?
>
> Sure, SEE ALSO sections is a proper place for citing alternatives, and
> detailing this is a *Perl* module would give pointers to the users (me
> included).
Well, actually what I did was take this change, another couple of
things (the example files, a small fix to the testing framework), and
just go ahead and release a new upstream version, confget-1.02.
A Debian package for it is available on mentors.d.n now:
http://mentors.debian.net/debian/pool/main/c/confget/confget_1.02-1.dsc
Let me know if you think that I should coalesce the changelog entries
into a single 1.02 "Initial release" one.
> It is still not very clear to me how to find the full configuration file
> syntax specification? Moreover there is neither a Standard nor a popular
> protocol which stipulates that. How are users supposed to know the gory
> details about it? Note that, "Anybody has looked at some INI files in the
> past" doesn't sound extremely promising ;-)
Unfortunately, as you say, there is no single standard for INI files.
The confget utility implements some of the more popular constructs -
sections (naturally), allowed whitespace in most positions, backslash
line continuations, comments (both "#" and ";"). There are things that
other parsers do that confget doesn't, like spaces *within* a variable
name; if there is popular demand, it may learn to do that, too :)
As to "how users are supposed to know", if this sentence of yours was
leading to the examples issue, see below :)
> > > It would be even better to include
> > > some short configuration files samples/examples in the binary package
> > > itself. Your own t{1|2}.ini should suffice.
> >
> > Ah, examples. An interesting, intriguing concept, indeed :)
> >
> > I'm not sure if t1.ini and t2.ini are really suitable as sample INI files;
> > they're more like silly, contrived, awful examples of the depths that
> > an INI file can sink to... But I could install them as examples, if you
> > think it's appropriate.
> >
> > I can't prepare a new package right now, but sometime tomorrow I'll see
> > what I can do about uploading a new version, if you think it's worth it.
>
> Sure, take your time. Examples are just good to have, although not mandatory.
> So, the only unclear point left is the configuration file syntax
> specification. This is not a hard showstopper, but would be very nice to have
> in place proper.
Version 1.02 of confget installs the t1.ini and t2.ini files as examples.
Since those files' purpose until now was indeed to be contrived edge
cases for regression testing, and examples are not generally supposed to
be that bad (at least, not *supposed* to ;), I added some comments in
those files so they are a bit more suitable.
Here's hoping you like version 1.02 better :)
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I were you, who would be reading this sentence?
Attachment:
pgp7oyVsdta7Q.pgp
Description: PGP signature