[lug] Perl question: how to print embedded metacharacters

[Chip Atkinson]

Thanks!  

The files are pretty much .ini type and are fairly short at the moment.
THey basically describe each sub-part of a log file entry and how it
should be split, formatted, and re-split.

I've wrestled with the idea of perl config files and I want to have a
program that I can hand off to someone to use that doesn't know much if
any perl.  The problem with using perl as a configuration file, as I see
it, is that it gives the user so much rope that pretty soon they are even
hanging their horse.  Once you start putting logic into the config file 
print abc if (/somepattern/);
then you start down the path of just having two programs -- the original
and the "config file" program.

Anyway, thanks again for the help. 

Chip

On Sun, 29 Nov 2009, Tkil wrote:

> >>>>> "Chip" == Chip Atkinson <chip at pupman.com> writes:
> 
> Chip> The most important thing is speed since the files are rather
> Chip> huge.  I think I'll implement the regex/hash approach tomorrow.
> 
> Curious how it worked out.
> 
> A good reason to use 'eval' directly is if you want to write your
> entire configuration file in perl itself.  (I'm pretty sure this is
> what Rob is doing.)
> 
> That has some advantages:
> 
>  * speed of parsing (relative to reading each line in perl, splitting
>    it however you need to, doing substitutions, and then stuffing it
>    in a data structure somewhere);
> 
>  * precision (can specify whitespace and other special characters very
>    precisely if necessary);
> 
>  * completeness (it /is/ perl, so you can represent any structure you
>    need to);
> 
>  * can be trivially rewritten (using Data::Dumper if nothing else).
> 
> But there are disadvantages:
> 
>  * editing the config in any non-trivial manner requires learning
>    perl, which is a non-trivial language (and config files would have
>    more obtuse corners than most).
> 
>  * if the files aren't entirely under your control, you open your
>    application up to attacks (similar in nature to sql injection
>    attacks, as mentioned in my reply to Rob).
> 
> There are some competing technologies here.  Obviously, XML works for
> interchange to non-Perl solutions; if you're staying within Perl,
> there was a lot of excitement over YAML a few years back as a more
> "human friendly" option.
> 
> There is the Windows-style INI file, and there are modules that parse
> those for Perl.
> 
> And then there's "roll your own".
> 
> We don't know all your constraints and preferences, so we can't say
> what's the right answer.  If your config files are "huge", however,
> I'm guessing that they're derived from (or lightly-edited versions of)
> some other file, so switching to pure perl for config seems unlikely,
> as is the switch to any other markup language.
> 
> So you're left with "roll your own" ... just make sure you define your
> own markup in a clean way!
> 
> Good luck,
> t.
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#hackingsociety
>