Hallo,
ich möchte Config variablen in eine externe Datei auslagern.
Da ich auf use strict nicht verzichten möchte muss ich wohl ebenfalls alle
configvariablen mit use vars deklarieren. Finde ich nicht so prickelnd,
einzig eine Lösung wäre dann ein hash um nicht alle einzelnd aufführen zu
müssen.
Wie macht Ihr das? Was ist ne schöne Lösung?
JT
* Jan Torben Heuer [2006-02-28]:
Hallo Jan Torben,
> ich möchte Config variablen in eine externe Datei auslagern.
welche Ansprüche hast du denn? Nur simple key/value Paare, oder auch mal
Listen, here-documents oder ähnliches?
Hast du dich schonmal in der Config::* Sektion des CPAN umgeschaut?
Wenn hierarchische Daten abgelegt werden sollen, dann könnte auch
einfaches XML interessant werden.
> Da ich auf use strict nicht verzichten möchte muss ich wohl ebenfalls alle
> configvariablen mit use vars deklarieren. Finde ich nicht so prickelnd,
> einzig eine Lösung wäre dann ein hash um nicht alle einzelnd aufführen zu
> müssen.
Heute[1] nimmt man statt 'use vars' eigentlich eher 'our'. Interessant
könnte auch 'use constant' sein. ([1] seit v5.6.0)
> Wie macht Ihr das? Was ist ne schöne Lösung?
Für simple Dinge wie
foo = bar
schreibe ich idR einen Dreizeiler.
Gruß
Christian
--
Snobs sind Leute, die sich ihre Petersilie mit
Fleurop in's Haus schicken lassen.
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Christian Lackas wrote:
>> ich möchte Config variablen in eine externe Datei auslagern.
>
> welche Ansprüche hast du denn? Nur simple key/value Paare, oder auch mal
> Listen, here-documents oder ähnliches?
Im moment nur $foo='bar'; und so, also key/value. Allerdings möchte ich mir
auch nicht die Möglichkeit von Arrays verbauen lassen.
> Hast du dich schonmal in der Config::* Sektion des CPAN umgeschaut?
> Wenn hierarchische Daten abgelegt werden sollen, dann könnte auch
> einfaches XML interessant werden.
overdressed, es geht so um host und porteinstellungen, username, passwort,
sowas halt.
> Heute[1] nimmt man statt 'use vars' eigentlich eher 'our'. Interessant
> könnte auch 'use constant' sein. ([1] seit v5.6.0)
Ok, das werde ich mal nachsschauen, aber our ist das selbe in Grün, oder?
Danke,
JT
Jan Torben Heuer
> Hallo,
>
> ich möchte Config variablen in eine externe Datei auslagern.
>
> Da ich auf use strict nicht verzichten möchte muss ich wohl ebenfalls alle
> configvariablen mit use vars deklarieren. Finde ich nicht so prickelnd,
> einzig eine Lösung wäre dann ein hash um nicht alle einzelnd aufführen zu
> müssen.
>
> Wie macht Ihr das? Was ist ne schöne Lösung?
>
Du könntest den Exporter verwenden. Oder tatsächlich ein Hash, das mit
Hash::Util::lock_keys geschützt ist (vor Tippfehlern, aber leider nur
während der Laufzeit feststellbar).
--
Slaven Rezic - slaven
BBBike - route planner for cyclists in Berlin
WWW version: http://www.bbbike.de
Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
Jan Torben Heuer schrieb:
> Christian Lackas wrote:
>>Hast du dich schonmal in der Config::* Sektion des CPAN umgeschaut?
>>Wenn hierarchische Daten abgelegt werden sollen, dann könnte auch
>>einfaches XML interessant werden.
>
> overdressed, es geht so um host und porteinstellungen, username, passwort,
> sowas halt.
Schau dir mal Config::Sofu an, das kann auch arrays und hashes mit
Verschachtelungen u.s.w.
Die Syntax ist relativ einfach und das system kann auch Datenstrukturen
dumpen, also brauchst du dir die Tipparbeit gar nicht machen.
Auch Kommentare in der Config-Datei bleiben bei dem Objekt bei dem sie sind.
Leider kann es keine Referenzen und undef, was aber an dem C-Interface
für Sofu liegt. Das Modul braucht auÃerdem Data::Sofu aber das sollte
kein Problem sein da beide Packete Pure-Perl sind.
Dein Vorteil ist, wenn du irgendwas nicht verstehst dann frag mich
einfach, denn ich hab's geschrieben.
Im Beispiel steht auch wie man das mit use strict macht.
--
$_='';s%%`^.*`s;.*;uhtnmo;;a>lha~a>inu~a>fmk~a>rou~a>duM~a>b tl~s;&&&&&&;
!d1!l2!b3!i4!f5!r6q(?);e;Z``}a>&&&`sub# "1#{#"_=shift#;s^"2^"3#^;``;~`
return #"_#}``^!&&`"1(#""2)#\.`Z%x;s~Z~print~g;s/#/\\/g;
s/`(.)(.+?)`(.+?)`/s$1$2$1$3$1g\;/gsx;s;&;(.);g;y^"^$^;print ;
Ich benutze
Data::Dumper
Ist ziemlich gut. Mit einem eval kann man die Variablen wieder
zurückbekommen.
Grüße,
Marco.
"Jan Torben Heuer"
news:du1r86$q6p$1@sagnix.uni-muenster.de...
> Hallo,
>
> ich möchte Config variablen in eine externe Datei auslagern.
>
> Da ich auf use strict nicht verzichten möchte muss ich wohl ebenfalls alle
> configvariablen mit use vars deklarieren. Finde ich nicht so prickelnd,
> einzig eine Lösung wäre dann ein hash um nicht alle einzelnd aufführen zu
> müssen.
>
> Wie macht Ihr das? Was ist ne schöne Lösung?
>
>
> JT
Post removed (X-No-Archive: yes)
* Stefan Trcek [2006-03-01]:
Hallo Stefan,
> my %cfg = do $cfg_file or die $!;
> die $@ if $@;
>
> In $cfg_file steht sowas wie
> return (
> host => "irgendwo",
> list => ["ein", "zwei"],
> );
das 'return' und die äußeren Klammern kann man sich dabei auch noch
schenken (und das Semikolon am Ende ja eh).
Gruß
Christian
--
Schulden haben auch Vorteile -- man bekommt viel Post.
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Stefan Trcek wrote:
> my %cfg = do $cfg_file or die $!;
> die $@ if $@;
So geht es nicht, da do(), wenn die Datei nicht gelesen
werden kann, undef liefert. Das führt nicht nur zu einer
unerlaubten Hash-Initialisierung mit nur einem Wert,
sondern, schlimmer noch, der "or die $!"-Teil wird nie
ausgeführt und der Fehler wird nicht erkannt.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
* Frank Seitz [2006-03-01]:
Hallo Frank,
> > my %cfg = do $cfg_file or die $!;
> > die $@ if $@;
> So geht es nicht, da do(), wenn die Datei nicht gelesen
> werden kann, undef liefert. Das führt nicht nur zu einer
> unerlaubten Hash-Initialisierung mit nur einem Wert,
> sondern, schlimmer noch, der "or die $!"-Teil wird nie
> ausgeführt und der Fehler wird nicht erkannt.
ja, Perl macht da intern ein
die $! unless my(%cfg) = do 'foo.pl';
draus. Es wertet also eigentlich den Wahrheitsgehalt erst nach Zuweisung
an die Variable wirklich aus. Das Problem ist hier also der erzwungene
Listenkontext.
Es bleibt einem also nur ein:
die $! if $!;
Perls Evaluierungsreihenfolge durch Verwendung von '||' zu umgehen geht
ja leider auch nicht, weil das den Listenkontext zerstört.
Gruß
Christian
--
Die beste Informationsquelle sind Leute, die versprochen haben, nichts
weiterzuerzählen.
(Marcel Mart, franz. Schriftsteller, *1948)
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Christian Lackas wrote:
> Es bleibt einem also nur ein:
>
> die $! if $!;
Das reicht nicht. Die direkte Zuweisung an den Hash ist
auch nicht sauber, weil do() im Fehlerfall undef liefert.
Der Code müsste korrekt ungefähr so aussehen:
my @arr = do $file;
die $@ || $! if @arr == 1;
my %cfg = @arr;
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
* Frank Seitz [2006-03-02]:
Hallo Frank,
> > Es bleibt einem also nur ein:
> > die $! if $!;
> Das reicht nicht. Die direkte Zuweisung an den Hash ist
> auch nicht sauber, weil do() im Fehlerfall undef liefert.
Der Fehler wird doch dann gemeldet, oder nicht? Ok, davor gibt es auch
noch zwei (berechtige) Warnungen.
> Der Code müsste korrekt ungefähr so aussehen:
> my @arr = do $file;
> die $@ || $! if @arr == 1;
> my %cfg = @arr;
Ist eine gute Idee.
Gruß
Christian
--
Spiritistische Sitzungen kann man leicht an ihrem Geruch erkennen.
http://www.lackas.net/ Perl Delphi Linux MP3 Searchengines Domainchecker
Jan Torben Heuer
> ich möchte Config variablen in eine externe Datei auslagern.
>
> [snip]
>
> Wie macht Ihr das? Was ist ne schöne Lösung?
Ich bin momentan ein Fan von YAML[1].
[1] http://search.cpan.org/dist/YAML/lib/YAML.pm
--
That is not dead, which can eternal lie,
and with strange aeons even death may die.
-- H.P. Lovecraft
Christian Lackas wrote:
> * Frank Seitz [2006-03-02]:
>>>Es bleibt einem also nur ein:
>>> die $! if $!;
>>
>>Das reicht nicht. Die direkte Zuweisung an den Hash ist
>>auch nicht sauber, weil do() im Fehlerfall undef liefert.
>
> Der Fehler wird doch dann gemeldet, oder nicht? Ok, davor gibt es auch
> noch zwei (berechtige) Warnungen.
Ja, der Fehler wird erkannt, aber die Warnungen
sind natürlich unerwünscht.
>>Der Code müsste korrekt ungefähr so aussehen:
>>my @arr = do $file;
>>die $@ || $! if @arr == 1;
>>my %cfg = @arr;
>
> Ist eine gute Idee.
Ehrlich gesagt, finde ich den Code grausam: man muss einen
(für den Arraykontext) unpassenden Returnwert behandeln,
zwei Fehlervariable auswerten und die gelieferten Daten durch ein
temporäres Array hindurchbefördern.
Viel schlimmer kann man eine Funktionsschnittstelle kaum vermurksen.
Zum Glück ist das für Perl ein untypischer Extremfall.
Bei einer generellen Fundierung auf Exceptions
(die in Perl leider, leider, leider nicht existiert)
wäre das nicht passiert.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Frank Seitz
> Bei einer generellen Fundierung auf Exceptions
> (die in Perl leider, leider, leider nicht existiert)
Die existieren nicht? Bilde ich mir
====
$ perl -e 'eval { 0 or die "foo\n"; }
or print STDERR "Exception caught: $@"; print "Continuing\n";'
Exception caught: foo
Continuing
====
nur ein?
-dnh
--
Eine kurze richtige Antwort (mancher mag sie als unfreundlich
bezeichnen) ist besser als eine lange, freundliche, falsche.
-- Dirk H. Hohndel
Jan Torben Heuer wrote:
> Hallo,
>
> ich möchte Config variablen in eine externe Datei auslagern.
>
> Da ich auf use strict nicht verzichten möchte muss ich wohl ebenfalls alle
> configvariablen mit use vars deklarieren. Finde ich nicht so prickelnd,
> einzig eine Lösung wäre dann ein hash um nicht alle einzelnd aufführen zu
> müssen.
Ich finde:
Eine Konfigurationsdatei ist kein Perl-Skript.
Da gehoert fuer mich ueberhaupt kein Perl-Kode rein.
Es gibt es zwar zwar erstklassige Anwendungen (OTRS z.B.),
die in Perl-Kode konfiguriert werden, ich finde das baeh.
Damit verwirrt man nur die paar Sysadmins, die kein Perl
lesen koennen (soll es unter Windows geben).
Besser finde ich es, wenn man die Sachen in ein Hash
oder ein hash-aehnliches Objekt a la Config::Tiny
einliest und dann im Skript sauber zuweist.
[OT] Auf den ersten Blick fand ich Config::Tiny unschoen,
weil es direkt auf die Eigenschaften des Objektes zugreift.
Bedenkt man aber, dass es ja sonst nicht viel hat und
macht, kann man damit leben. [/OT]
Man kann sich aber auch leicht etwas von Hand stricken,
dass eine .ini-Datei (oder ein anderes zu einfaches
Format) lesen und in ein Hash, HoH, HoA, oder was immer
gebraucht wird, einliest.
Es folgt ein ungetestetes Beispiel.
Im Perl-Skript:
use Config::Tiny;
my $config = Config::Tiny->read("setup.ini");
my $dbName = $config->{db}->{name};
my $proxyHost = $config->{proxy}->{hostname};
my $proxyPort = $config->{proxy}->{port} || '8080';
my $appName = $config->{_}->{application};
Die Konfigurations-Datei setup.ini:
# Allgemeine Parameter:
application=Konfigurationtest / Beispiel
# Hier kommt die DB-Konfiguration:
[db]
name=testdb
[proxy]
hostname=safersurf.pornostars.org
port=69
David Haller wrote:
> Frank Seitz
>>
>>Bei einer generellen Fundierung auf Exceptions
>>(die in Perl leider, leider, leider nicht existiert)
>
> Die existieren nicht? Bilde ich mir
>
> ====
> $ perl -e 'eval { 0 or die "foo\n"; }
> or print STDERR "Exception caught: $@"; print "Continuing\n";'
> Exception caught: foo
> Continuing
> ====
>
> nur ein?
Klar hat Perl Exceptions. Sogar Objekte kann man werfen.
Nur leider macht Perl selbst davon keinen bzw. nur
rudimentären Gebrauch (die grundsätzliche Abstützung darauf
fehlt). In der Perl-Welt werden Fehler meist über
Returnwerte angezeigt, was ich sehr anachronistisch finde.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Ich benutze folgendes:
1) In einer eigenen Datei schreibe ich die Werte (perl-like)
zB.
$INIT=3D'myINIT';
%HASH=3D( Key1=3D>'value1', Key2=3D>'value2');
usw.
2) Im Skript :
use strict;
{ package Config; do "datei.ini" }
[..]
# Zugriff
my $init_Wert=3D $Config::INIT;
Gruß
drm
drm wrote:
> Ich benutze folgendes:
>
> 1) In einer eigenen Datei schreibe ich die Werte (perl-like)
> z.B.
> $INIT='myINIT';
> %HASH=( Key1=>'value1', Key2=>'value2');
> usw.
>
> 2) Im Skript :
> use strict;
> { package Config; do "datei.ini" }
>
> [...]
>
> # Zugriff
> my $init_Wert= $Config::INIT;
Im Vergleich zum ursprünglichen Vorschlag etwas umständlich.
Und die Fehlerbehandlung fürs do() hast Du Dir garnicht erst angetan.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Tony Muler wrote:
> Eine Konfigurationsdatei ist kein Perl-Skript.
> Da gehoert fuer mich ueberhaupt kein Perl-Kode rein.
> Es gibt es zwar zwar erstklassige Anwendungen (OTRS z.B.),
> die in Perl-Kode konfiguriert werden, ich finde das baeh.
> Damit verwirrt man nur die paar Sysadmins, die kein Perl
> lesen koennen (soll es unter Windows geben).
Full ACK!
Ich bin zwar nicht der Perl-Profi, aber es gilt doch als allgemein nicht
anstrebenswert (egal welche Sprache), Konfigurationsdateien, auf die der
Nutzer/Admin zugreifen koennen soll, in eine Programmiersprache zu
verfassen. Das schafft nur Unverstaendnis.
Uebliche Formate sind z.B. INI-Dateien || XML-Dateien
Wie INI-Dateien in Perl genutzt werden koennen weiss ich nicht, aber XML
ist doch recht einfach einzubinden.
just my 5cents
MfG, Ulf
Ulf Kadner
> Tony Muler wrote:
>
> > Eine Konfigurationsdatei ist kein Perl-Skript.
> > Da gehoert fuer mich ueberhaupt kein Perl-Kode rein.
> > Es gibt es zwar zwar erstklassige Anwendungen (OTRS z.B.),
> > die in Perl-Kode konfiguriert werden, ich finde das baeh.
> > Damit verwirrt man nur die paar Sysadmins, die kein Perl
> > lesen koennen (soll es unter Windows geben).
>
> Full ACK!
>
> Ich bin zwar nicht der Perl-Profi, aber es gilt doch als allgemein
> nicht anstrebenswert (egal welche Sprache), Konfigurationsdateien, auf
> die der Nutzer/Admin zugreifen koennen soll, in eine
> Programmiersprache zu verfassen. Das schafft nur Unverstaendnis.
Es verlangt auch niemand, die komplette Programmiersprache beherrschen
zu können, sondern nur die Darstellung von (komplexen) Datenstrukturen
in Perl. Etwas in der Art von:
(
foo => "bar",
bla => [1,2,3,4],
)
sollte jeder Admin verstehen können.
>
> Uebliche Formate sind z.B. INI-Dateien || XML-Dateien
>
> Wie INI-Dateien in Perl genutzt werden koennen weiss ich nicht,
Da gibt es eine Unmenge von Modulen. Aber klassische INI-Dateien sind
flach. Wenn man komplexe Datenstrukturen unterbringen will, muss man tricksen.
> aber
> XML ist doch recht einfach einzubinden.
Leider nicht. Ich möchte eigentlich nur eine einzige Funktion
aufrufen, um eine Konfigurationsdatei einzulesen. Leider beißen sich
das Datenmodell von XML und Perl (und anderen Programmiersprachen), so
dass man immer einen Konverter schreiben muss.
Gruß,
Slaven
--
Slaven Rezic - slaven
sf-upload: make batch releases on SourceForge
http://sf-upload.sf.net
Slaven Rezic wrote:
> Ulf Kadner
>>
>>Ich bin zwar nicht der Perl-Profi, aber es gilt doch als allgemein
>>nicht anstrebenswert (egal welche Sprache), Konfigurationsdateien, auf
>>die der Nutzer/Admin zugreifen koennen soll, in eine
>>Programmiersprache zu verfassen. Das schafft nur Unverstaendnis.
>
> Es verlangt auch niemand, die komplette Programmiersprache beherrschen
> zu können, sondern nur die Darstellung von (komplexen) Datenstrukturen
> in Perl. Etwas in der Art von:
>
> (
> foo => "bar",
> bla => [1,2,3,4],
> )
>
> sollte jeder Admin verstehen können.
Wobei man (wie ich auch gerade erst gelernt habe), die
äußeren Klammern sogar weglassen kann!
Dass es sich um interpretierten Perl-Code handelt, sieht man
kaum mehr, es steht aber die volle Ausdruckmächtigkeit der
Sprache zur Verfügung, wenn man sie braucht.
Darin liegt allerdings auch eine Gefahr, da der Anwender
über so eine Datei beliebigen Code in das Programm
einschleusen kann.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Frank Seitz
> Slaven Rezic wrote:
> > Ulf Kadner
> >>
> >>Ich bin zwar nicht der Perl-Profi, aber es gilt doch als allgemein
> >>nicht anstrebenswert (egal welche Sprache), Konfigurationsdateien, auf
> >>die der Nutzer/Admin zugreifen koennen soll, in eine
> >>Programmiersprache zu verfassen. Das schafft nur Unverstaendnis.
> >
> > Es verlangt auch niemand, die komplette Programmiersprache beherrschen
> > zu können, sondern nur die Darstellung von (komplexen) Datenstrukturen
> > in Perl. Etwas in der Art von:
> >
> > (
> > foo => "bar",
> > bla => [1,2,3,4],
> > )
> >
> > sollte jeder Admin verstehen können.
>
> Wobei man (wie ich auch gerade erst gelernt habe), die
> äußeren Klammern sogar weglassen kann!
>
> Dass es sich um interpretierten Perl-Code handelt, sieht man
> kaum mehr, es steht aber die volle Ausdruckmächtigkeit der
> Sprache zur Verfügung, wenn man sie braucht.
>
> Darin liegt allerdings auch eine Gefahr, da der Anwender
> über so eine Datei beliebigen Code in das Programm
> einschleusen kann.
Ich benutze für Perl-Konfigurationsdateien Safe::do oder Safe::reval
statt do/eval. Wobei man auch hier keine 100%ige Sicherheit erwarten
kann.
Gruß,
Slaven
--
Slaven Rezic - slaven
Dump a Tk canvas as an xfig file:
http://search.cpan.org/search?mode=module&query=Tk::CanvasFi g
Post removed (X-No-Archive: yes)