Hey, nice can of worms you opened here toma!

So here is a summary of what we've got so far. Let me know if you feel like adding more module/options or other fields:

Update: added Boulder as suggested below.

Nice comparison! And yeah, why not add Boulder by Lincoln Stein.

Update: Boulder is a data format used internally in CGI.pm's query persistence. Here's an excerpt from perldoc CGI.

=head2 SAVING THE STATE OF THE SCRIPT TO A FILE:

    $query->save(FILEHANDLE)

This will write the current state of the form to the provided
filehandle.  You can read it back in by providing a filehandle
to the new() method.  Note that the filehandle can be a file, a pipe,
or whatever!



The file format used for save/restore is identical to that used by the
Whitehead Genome Center's data exchange format "Boulderio", and can be
manipulated and even databased using Boulderio utilities.  See

  http://stein.cshl.org/boulder/

for further details.
[download]

--
Tatsuhiko Miyagawa
miyagawa@cpan.org

FWIW, I posted Data::PropertyList to CPAN a couple of years ago, which supports the "property list" format for configuration data originally used by NeXT.

It's a text format with support for nested data structures, designed to be human-editable, and does not use evals, which puts it somewhere between Data::Denter and Inifile in terms of flexibility.

Apple has switched to using an XML encoding for these data structures in MacOS X, so this file format is probably only of historical interest at this point...

Actually, WindowMaker uses the property list format for it's menus and other files.

Parse::RecDescent is quite capable of reading any kind of configuration file. In fact, you could write a configuration file manager, using other modules to write the config files. That might be cool. And slow.

If you choose XML you can either use XML::Simple (just make sure you read the docs carefully, simple can be a deceptive name ;-), or Data::DumpXML, which is very convenient too.

Going the pure-Perl way I would tend to use Data::Denter which I find to be easier to read than Data::Dumper and more convenient, as you don't have to eval the saved data, but just use undent.

If you are looking for speed then Storable is most likely to be the fastest though.

And note that none of these methods can store code references (subs).

use DB_File;
tie %hash, "DB_File", $filename or die "NO DIE\n";
%hash{key}='value';
untie %hash;
[download]

-----------------------------------
--the good, the bad and the physi--
-----------------------------------
[download]

Binary config files are evil. Somebody with more experience told me that even Unix used once binary config files (like, for example, sendmail still seems to do and the mailman program (written in Python) does), and it opens a whole can of worms, like version dependencies, platform dependencies and general unmodifiability of the config file if the program used to create it dosen't start anymore.

Just imagine a version of Perl linked to another (version of) Berkeley DB, or that you want to transfer your config files between machines with different endianness, or between Windows and Unix, where all the path names change.

Or imagine the hell if the program crashes while writing the configuration file, and won't start up anymore, because the config file is broken, and you have no easy way to tell if the file is complete, and no easy way to fix/salvage the current configuration or what's left of it...

If you don't trust binary files then maybe a better way will be, to use DBI and CSV like that:

tie %line, 'Tie::RDBM', "CSV:f_dir=/whatever/log", {table => 'anyfilen
+ame', create => 1} or die "no tie $!\n";
[download]

Then you get a human readable file, which is editable.

-----------------------------------
--the good, the bad and the physi--
-----------------------------------
[download]

--
Tatsuhiko Miyagawa
miyagawa@cpan.org

You could also just do an eval on the file in which case it could hold code itself too but most people don't do that (I think Larry Wall did once though).

Finally DBD::RAM can freeze/thaw data structures:

DBD:RAM can import data directly from references to
arrays of arrayrefs and references to arrays of hashrefs.
This allows you to easily import data from some other
portion of a perl script into a database format and either
save it to disk or simply manipulate it in memory.
[download]

Actually DBD::RAM as been superseded by DBD::AnyData (works with DBI) and Anydata ("standalone" version), by the same author

You might want to check out Petruchio's Tk::Style. It uses XML::Parser to store Tk widget options... And does pretty much all the work of getting those options to the proper widgets for you. I'm sure you could figure out a way to also add in miscellaneous other options (ie, file paths) in the same file.

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

   larryk                                          
perl -le "s,,reverse killer,e,y,rifle,lycra,,print"

Two possibilites are AppConfig and Config::IniFiles

Config::Inifiles supports tying/persistance, cannot vouch for AppConfig.

If people need to be able to vi the file, use Andy Wardley's nice AppConfig module. It can merge in overrides from the command line, handle site-wide configs, etc.