[Discuss] Application config files

[abreauj at gmail.com (John Abreau)]

Is there a convention for multi-line records in .ini files?

I've been using .ini files extensively for over 20 years now, having long
ago rolled my own tools for reading them, and when I needed multi-line
records, I just incorporated the syntax of here-documents from the UNIX
shell. For example:

[events]
> id=2019-jul
> date=2019-07-17
> start=6:30 pm
> stop=9:00 pm
> location=mite51-315
> organization=blu
> topic=Our 25th Anniversary
> summary=A look back at our history
> abstract << EOF
> Boston Linux & UNIX was founded in 1994, originally as a Special Interest
> Group  (SIG) of The Boston Computer Society (BCS). When the BCS
> dissolved itself in 1996, our group's volunteer team chose to continue as
> an independent user group.
>
> We celebrate our 25th anniversary this month with pizza and cake, and a
> retrospective look at our group's history.
> EOF
> confirmed=t
>

If there's a standards-compliant alternative for handling this, then I'd be
able to use standard INI-processing tools.


On Thu, Jul 18, 2019 at 12:48 AM John Hall <johnhall2.0 at gmail.com> wrote:

> Use a standard library configuration file parser rather than rolling your
> own.
> For example configparser standard lib will provide your code with read and
> write for ini files. There is no reason to introduce parsing errors or
> vulnerabilities by rolling your own parser.
> I would maintain the defaults as python code to generate the file if no ini
> file is found rather than checking the ini file into version control.
> Add a format version number to the ini file if you foresee a need to
> migrate settings after updates. __fmt_ver_num  really is friendly enough.
> Decide if users are going to use the gui or just edit the file, or separate
> concerns and have gui related settings handled by the gui and have the user
> edit the end of the file for all other settings.
>
> I prefer to edit a file list in a file editor not in a little box.
>
> Most linux settings files have their own  format. I agree that a standard
> format is preferable for most apps but i really do not care or believe it
> makes any difference which one you choose.
>
> On Sat, Jul 13, 2019 at 8:17 PM Steve Litt <slitt at troubleshooters.com>
> wrote:
>
> > On Fri, 12 Jul 2019 16:16:15 -0500
> > Derek Martin <invalid at pizzashack.org> wrote:
> >
> > > On Fri, Jul 12, 2019 at 02:07:20PM -0400, Steve Litt wrote:
> > > > On Fri, 12 Jul 2019 13:40:01 -0400
> > > > Dan Ritter <dsr at randomstring.org> wrote:
> > > >
> > > > > Jerry Feldman wrote:
> > > > > > I have an application that I wrote where I am using a .ini style
> > > > > > file for config. I chose that as an afterthought but maybe JSON,
> > > > > > YAML, or TOML might be better formats.
> > >
> > > > JSON is out from the get-go: It's not meant to be read and written
> > > > by humans.
> > >
> > > I largely disagree.  If it's currently in INI format the equivalent
> > > JSON should generally be perfectly human-readable, e.g.:
> > >
> > {"thingy": {"name":  "foo","ip": "10.1.2.3", "value": 1,
> > "live":  true, "notes": null}}
> >
> > Your assertions (not copied here) about Python writing beautful
> > json is true, but humans, not so much. One could easily write a Python
> > json beautifier to help, but I still think complex json is hard for a
> > human to edit.
> >
> > I think about 20 lines of Python could turn an .ini file into a list of
> > dicts.
> >
> > SteveT
> >
> > Steve Litt
> > July 2019 featured book: Troubleshooting Techniques
> >      of the Successful Technologist
> > http://www.troubleshooters.com/techniques
> > _______________________________________________
> > Discuss mailing list
> > Discuss at blu.org
> > http://lists.blu.org/mailman/listinfo/discuss
> >
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>


-- 
John Abreau / Executive Director, Boston Linux & Unix
Email: abreauj at gmail.com / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6
PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23  C2D0 E885 E17C 9200 63C6