Diskussion:Perl-Programmierung

Neue Beiträge bitte unten anhängen

Ältere Diskussionen werden im Perl-Archiv aufbewahrt.

Todo-Liste

1. Bitte auf der Projektseite die Statusanzeiger pflegen. Ich habe die vorerst alle auf 0 gestellt --Turelion 09:07, 15. Jul. 2007 (CEST)
2. Einige Topics sind noch gänzlich unbearbeitet. Fachleute, bitte melden!! --Turelion 09:07, 15. Jul. 2007 (CEST)
   1. Perlschnittstellen, namentlich Perl/QT, Perl/GTK, Perl/wxWidgets, mod_perl: Perl-Beschleunigung unter Apache, und die allgemeine Anleitung zu CPAN.
3. Wie sich gezeigt hat, sind die Beispiel-Programme nicht ganz koscher, und sollten samt und sonders mal getestet werden. Anschließend sollte ein Vermerk <!-- ERFOLGREICH GETESTET --> im Seitentext direkt vor dem betreffenden Quellcode hinterlegt werden. Wer seine Programme in Wikibooks statt auf dem heimischen System entwickelt (schämt euch ;-)) sollte ab jetzt wenigstens ein <!-- NOCH NICHT ERFOLGREICH GETESTET --> voranstellen. Folgende Kapitel wurden diesbezüglich schon komplett abgearbeitet:
   1. Seiten ohne Quelltext: Vorwort, Projektdefinition, Kurzvorstellung, Das Richtige für mich, Eintauchen in die Perlenwelt, Geschichte, Larry und die Perl-Kultur, Installation.
4. Im Buchgespräch wurde mal in einem Nebensatz vorgeschlagen, jedes Kapitel mit einer Anekdote als Einleitung auszustatten. Ist zwar keine Sache der Notwendigkeit, aber Turelion 13:58, 1. Feb. 2008 (CET) wollte es hier nochmal in Erinnerung rufen. Vielleicht erbarmt sich ja jemand. ^^

Weitere Vorschläge

1. Data::Dumper frühzeitig einführen, das hilft bei der Entwicklung immens
2. Perl-Debugger, oder ein anderes REPL ???, frühzeitig erwähnen. Nützlich zum Ausprobieren
3. Perl::Tidy erklären
4. Arbeiten mit CPAN sollte Teil des Einstieges sein
5. Perl::Critic find ich persönlich toll, ist IMHO für ein Anfängerbuch zu speziell
6. Die Funktionsreferenz würde ich ganz weglassen. Es gibt bessere Quellen dafür. Anstattdessen würde ich ausführlichere Kapitel wie Arbeiten mit Arrays, Arbeiten mit Hashes, Datum und Zeit anlegen.
7. Moderne Web-Frameworks wie Catalyst und Mason werden garnicht erwähnt
8. Ein Beispiel mit HTML::Template wäre nicht schlecht
9. In OOP sollte könnte man gleich auf Moose verweisen
10. Die Bitoperatoren werden höchst selten gebraucht, eine kurze Erwähnung genügt
11. Erstellen von Modulen mit Module::Starter
12. Testmodule
13. CGI::Simple anstatt das in die Jahre gekommene CGI.pm
14. Vorschlag: Bundle::Wikibook::German in CPAN, um die besprochenen Module zu installieren, kein Task::Kensho bitte
15. nützliche Perl Einzeiler

BernhardSchmalhofer 11:43, 13. Apr. 2009 (CEST)

Thematische Diskussionen

Fallunterscheidungen

Mir ist an folgendem Progrämmchen eine Kleinigkeit an Perl aufgefallen:

#!/usr/bin/perl

use strict;

my $c=$ARGV[0];

if($c) {print "Wahr\n";}
else {print "Falsch\n";}

Beobachtung: "Falsch" wird ausgegeben, wenn $c==0 oder wenn $c undef ist. Sonst wird "Wahr" ausgegeben.

Das mag vielleicht nichts Waldbewegendes sein, aber Programmierfüchse finden dadurch bestimmt einen Weg, ihren Quelltext zu verkürzen und zu vereinfachen.

Könnt Ihr die Beobachtung bestätigen? Ist das wichtig genug, um im Buch erwähnt zu werden?

--Turelion 17:43, 1. Jan. 2008 (CET)

Juhu Turelion,

ich verstehe Dich nicht ganz. Ich vermute, dass Du eine Bemerkung sehen möchtest, die beschreibt, auf welche Weise man in Perl einen logisch falschen Wert aufschreiben kann. In der Tat geht das in Perl auf mannigfaltige Weise :-)

Beispiele sind 0, undef, "0" und ().

Es sollte in der Tat einen Abschnitt über Wahrheit geben. Dort sollte als Leckerli dann vermutlich auch "0 but true" erläutert werden :-D --Glauschwuffel 08:33, 3. Jan. 2008 (CET)

Hallo Glauschwuffel,

Ja, im Prinzip trifft Dein letzter Absatz es genau: Ein umfassender Abschnitt über Wahrheit/Falschheit in Perl. Ich glaube, sowas ist noch nicht da. Den Ausdruck "0 but true" finde ich klasse!!!!

Gruß, Turelion 17:22, 3. Jan. 2008 (CET)

Wo würden wir den Abschnitt ansiedeln? Das Thema ist grundlegend, sollte also vielleicht schon am Anfang auftauchen. Eventuell reicht dort aber auch eine einfache Bemerkung der Art

Alles, was nicht falsch ist, ist wahr. 0, undef und was dazu evaluiert wird, ist falsch. Mehr dazu im Abschnitt X.

Abschnitt X ist dann im zweiten Teil des Buches. Meinungen? --Glauschwuffel 08:19, 4. Jan. 2008 (CET)

Am Besten würde es IMHO hierhin passen, als Nachbemerkung oder Zusatzerläuterung oder irgendwas.

Ich glaube nicht, daß wir Einsteiger davor verschonen müssen, und ich glaube, das Thema ist nicht groß genug für einen zweiten Abschnitt. Wie gesagt, es ist nur eine Kleinigkeit.

Ich hätte es selbst schon eingebaut, aber ich habe so ein Händchen dafür, unverständlich zu erklären. Wie Du ja an meinem ersten Posting schon selbst erlebt hast!! ^^ --Turelion 19:54, 4. Jan. 2008 (CET)

Pragmas

Hi zusammen,

unter Hello World (Stichwort Querverweise) habe ich den oben angegebenen, noch ins Leere führenden Verweis gefunden. Irgendwann könnte sich einer unserer Leser berufen fühlen, den mit Inhalt zu füllen. Von der Hauptseite führt jedoch kein Verweis dorthin.

Ich kenne mich mit Pragmas eigentlich nicht richtig aus. Sind die ein Thema für ein eigenes Kapitel? Wenn ja, wo gehört das hin? Oder sollten wir den Verweis einfach kommentarlos löschen? Die Pragmas strict und warnings werden auch in dem anderen Verweis erläutert, und wenn es dort noch an Ausgiebigkeit fehlt, sollten sie auch dort ergänzt werden. --Turelion 10:03, 1. Feb. 2008 (CET)

Moin Turelion,

das war ich :-)

Mein Idee war tatsächlich, einen Abschnitt über zumindest die gängisten Pragmata zu verfassen. Aufgrund externer Faktoren wie Hausbau und Diplomarbeit und Job bin ich dann aber natürlich nicht dazu gekommen. Es gibt eine Handvoll Pragmata (das sind ganz grob gesagt die klein geschriebenen), da kann man schon eine Menge zu schreiben. Insbesondere utf8 öffnet eine große Dose mit vielen Würmern :-)

Meinetwegen kann der Verweis erst einmal weg, dann packe ich ihn zu gegebener Zeit wieder rein. --Glauschwuffel 14:59, 12. Feb. 2008 (CET)

Ok, machen wir es so. --Turelion 21:54, 12. Feb. 2008 (CET)

Grenzbereiche der Projektrichtlinien

Hi zusammen,

bei der Anpassung von Variablen bin ich auf einige ein- oder zweizeilige Code-Fragmente gestoßen, die trotzdem (unter der Voraussetzung, daß deren Datei von der Kommandozeile aus direkt an den Interpreter übergeben wird: perl beispieldatei.pl) alleine lauffähig wären. Kann man die so belassen? Müssen die mit Shebang und Pragmas ausgestattet werden?

Das bringt mich zu der ergänzenden Frage, ob Code-Fragmente, die NICHT alleine lauffähig sind, entsprechend gekennzeichnet werden sollten (analog zu <!--ERFOLGREICH GETESTET> zum Beispiel mit <!--CODEFRAGMENT-->, oder ob das schon wieder zuviel typisch deutscher Bürokratismus wäre.

Beste Grüße, --Turelion 10:03, 1. Feb. 2008 (CET)

Vielleicht kann man da eine kleine Vorlage basteln, die das als Hinweis für den Leser klein unter den Code schreibt? Gibt's das für andere Sprachen am Ende schon? --Glauschwuffel 15:02, 12. Feb. 2008 (CET)

Titelbild

Hi zusammen,

Ich habe Benutzer:Philipendula gebeten, uns einen Entwurf für ein Titelbild anzufertigen. IMHO hat sie es schon mal sehr gut gemacht, möchte aber noch ein paar Ergänzungen einarbeiten. Damit Ihr schon mal einen 1. Eindruck habt:

--Turelion 17:23, 13. Feb. 2008 (CET)

Bei der Benutzung des Kamels in Zusammenhang mit Perl muss man vorsichtig sein. Der Verlag O'Reilly hält darauf ein Copyright. Bei der YAPC::EU in München hat wir ein Kamel im Logo und mussten dazu die Erlaubniss von O'Reilly einholen.

--BernhardSchmalhofer 12:07, 10. Apr. 2009 (CEST)

Verdeckungsregel

Welche Verdeckungsregel gilt denn in Perl oder anders gefragt: wenn ich in einem Block eine Variable deklariere, die es unter dem gleichen Namen im umgebenden Block bereits gibt, gilt dann die innere Definition im gesamten inneren Block oder erst ab der Deklaration? Ich persönlich finde, dass diese Frage im Kapitel Gültigkeitsbereich von Variablen behandelt werden sollte. --Daniel Mex 00:16, 16. Apr. 2008 (CEST)

Hallo Daniel, zunächst fühle ich mich auch ein wenig unsicher bei der Frage. Ich denke aber, daß das mit einem Skript nachprüfbar ist. Ich stelle mir ein Skript vor, daß für jeden denkbaren Einzelfall ein Perl-Programm erzeugt, startet und die von diesem erzeugten Systemmeldungen mitloggt. Jetzt müßte man sich nur noch einigen, welche Einzelfälle denkbar sind. Meine Gedanken sind zunächst folgende: Variablendeklaration kann mit 1. my, 2. our und 3. mit local geschehen. Variablendeklaration kann stattfinden im Hauptteil, in einer Unterfunktion 1. Grades (Aufruf vom Hauptteil aus.) und in einer Unterfunktion n. Grades (Aufruf von einer Unterfunktion aus). Welche Vorraussetzungen hältst Du für einen Test für sinnvoll? Hast Du noch ein paar zusätzliche zu berücksichtigende Voraussetzungen? --Turelion 20:04, 18. Apr. 2008 (CEST)

Diese Voraussetzungen erscheinen mir schon sinnvoll, ich weiß aber auch nicht, ob es noch andere Bedingungen gibt, von denen das abhängt. Interessant wäre vielleicht noch, ob für Subroutinen die gleiche Verdeckungsregel wie für Variablen gilt. --Daniel Mex 01:03, 19. Apr. 2008 (CEST)

Testskript

#!/usr/bin/perl
#
use strict;
use warnings;

my @deklarationen=("local", "my", "our");
my $output="";

for my $top (@deklarationen) {
  for my $middle (@deklarationen) {
    for my $bottom (@deklarationen) {
      open (OUT, ">test$top$middle$bottom.pl") || die "Datei test$top$middle$bottom.pl kann nicht zum beschreiben geöffnet werden\n";
      $output=<<OUTPUT;
#!/usr/bin/perl
#
use strict;
use warnings;

$top \$a=1;
$top \$b=func1();
print \$a+\$b . "\n";

sub func1{
  $middle \$a=1;
  $middle \$b=func2();
  return \$a+\$b;
}

sub func2{
  $bottom \$a=1;
  $bottom \$b=2;
  return \$a+\$b;
}

OUTPUT
      print OUT $output;
      close(OUT);
      open (LOG, ">>declare.log") || "Log-Kommentar konnte nicht erstellt werden\n";
      print LOG "##### $top ##### $middle ##### $bottom #####\n";
      close(LOG);
      open (PIPE, "perl -f test$top$middle$bottom.pl >> declare.log 2>> declare.log|") || die "Die Log-Pipe konnte nicht gestartet werden\n";
      close (PIPE);
    }
  }  
}

Ausgabe:

 $ ./createdeklarationtestskripts.pl 
 Useless use of a constant in void context at ./createdeklarationtestskripts.pl line 38.

(Keine Ahnung, was mir die Warnung sagen soll.)

Declare.log:

##### local ##### local ##### local #####
5
##### local ##### local ##### my #####
5
##### local ##### local ##### our #####
5
##### local ##### my ##### local #####
5
##### local ##### my ##### my #####
5
##### local ##### my ##### our #####
5
##### local ##### our ##### local #####
5
##### local ##### our ##### my #####
5
##### local ##### our ##### our #####
5
##### my ##### local ##### local #####
Can't localize lexical variable $a at testmylocallocal.pl line 12.
##### my ##### local ##### my #####
Can't localize lexical variable $a at testmylocalmy.pl line 12.
##### my ##### local ##### our #####
Can't localize lexical variable $a at testmylocalour.pl line 12.
##### my ##### my ##### local #####
Can't localize lexical variable $a at testmymylocal.pl line 18.
##### my ##### my ##### my #####
5
##### my ##### my ##### our #####
5
##### my ##### our ##### local #####
Can't localize lexical variable $a at testmyourlocal.pl line 18.
##### my ##### our ##### my #####
5
##### my ##### our ##### our #####
5
##### our ##### local ##### local #####
5
##### our ##### local ##### my #####
5
##### our ##### local ##### our #####
5
##### our ##### my ##### local #####
5
##### our ##### my ##### my #####
5
##### our ##### my ##### our #####
5
##### our ##### our ##### local #####
5
##### our ##### our ##### my #####
5
##### our ##### our ##### our #####
5

Die Warnung ist tatsächlich ein bisschen seltsam. Hinter dem || Operator in der Zeile die das Log-File öffnet befindet sich nur eine Text-Konstante. Da der gesamte Ausdruck, im void-Kontext steht, warn perl davor das sie etwas nutzlos ist, da sie weder in einer Variable gespeichert wird, noch auf eine andere Art und Weise verarbeitet wird.

Die Warnung wird offensichtlich während der Übersezung generiert, da bei der Ausführung dieser Fall nicht eintritt. Falls das open Fehlschlägt würdest du es aber erst an der Warnung write to closed filehandle (kann im original abweichen) merken.

Die Verdeckungsregeln sind in perl eigentlich auch nicht schwer zu erklären. Lexikalische Variablen (mit my deklarierte) folgen dem in vielen Sprachen verwendeten Schema das eine lexikalische Variable in einem inneren Block die im äußeren Block verdeckt. mit our deklarierte Variablen verhalten sich anders, da sie ja alle ein und die selbe Variable definieren, dort hängt es vom Namensraum (package) ab und nicht von dem Block in dem sie verwendet werden. Interessant ist eigenlich nur der Sonderfall, dass lexikalische Variablen die dynamischen verdecken können, was ja nicht weiter schlimm ist. Heuzutage sollte local nicht mehr verwendet werden um Variablen zu deklarieren, da es sich wie our verhält, aber den Gültigkeitsbereich des Werts beschränkt. Das ist zwar scheinbar nur eine Konvention, meiner Meinung nach aber auch eine sinnvolle. (Ich finde die Funktionsweise von local eben so cool, dass ich es als Abwertung verstehen würde, wenn es für eine schnöde Variablendefinition eingesetzt wird.)

Zur zeit gibt es in perl keine lexikalischen Subroutinen. Sie sind wohl aber geplant und ich weiß nicht genau ob sie eventuell auch schon mit Version 5.10 implementiert wurden. Deshalb verhalten sich Subroutinen wie mit our deklarierte Variablen. Es kann pro package immer nur eine mit dem selben Namen geben. Dabei ist dann wohl eher die Reihenfolge der Ausführung auschlaggebend, als die tiefe des Blocks in dem sie sich Funktionsdefinition befindet.

happy perl hacking Giftnuss 22:14, 22. Apr. 2008 (CEST)

Zunächst mal danke für die Informationen und das Testskript. Finde ich sehr interessant. Ihr geht allerdings schon über das hinaus, was ich ursprünglich wissen wollte, nämlich ob vor der Deklaration die innere oder die äußere Definition gilt. Für our ist diese Frage nach der Erklärung hinfällig. Für local und my haben einige Tests ergeben, dass vor der Deklaration die äußere Variable gilt, was der Regel in C und C++ entspricht. Eine Ausnahme stellt der Fall dar, dass die äußere mit my und die innere mit local deklariert wurde, aber du (@Giftnuss) hast ja schon erklärt, dass local den Gültigkeitsbereich beschränkt. --Daniel Mex 01:03, 23. Apr. 2008 (CEST)

Verwirrung: Warum "my"?

Hallo! Ich bin totaler Anfänger in Perl, kenne aber andere Programmiersprachen. Im ersten Beispielcode "Zahlen" wird gezeigt, wie man Variablen definiert. Danach kommt ein Beispiel, und vor allen Variablen steht das Wörtchen "my". Warum? Wird leider im Text nicht erläutert. Ich denke mal, es ist eine Art Definition des Geltungsbereiches (wie private/public in C# oder Java). Was ist die Alternative zu "my"? Kann man es weglassen? Gruß, Stephan --84.190.51.115 17:13, 3. Sep. 2008 (CEST)

Hilft Dir das hier weiter? Schreib doch bitte ein Feedback hierher, --Turelion 21:45, 3. Sep. 2008 (CEST)

Ja, genau was ich suchte. Danke! Soweit war ich einfach noch nicht. Einen Hinweis in diesem Kapitel fänd' ich trotzdem nicht schlecht. --84.190.51.115 11:22, 4. Sep. 2008 (CEST)

Stimmt, werde ich morgen reinsetzen. Mich würde nur interessieren, wie Du mit dem Kapitel zurecht kommst. Ich habe es nur quer gelesen, und hatte den Eindruck, daß es recht unverständlich und abschreckend geschrieben ist, aber vielleicht täusche ich mich einfach nur. --Turelion 22:42, 4. Sep. 2008 (CEST)

Habe mir erlaubt das Variablen-Beispiel mit der Verknüpfung auf den Geltungsbereich zu versehen. --ap0calypse 16:13, 8. Sep. 2008 (CEST)

Hallo Ap0calpyse, schön, mal wieder von Dir zu lesen. Prinzipiell Ok, aber ich finde, der Begriff Geltungsbereich ist noch erklärungsbedürftig, gerade für Anfänger. Nach meiner Erfahrung hängt das nicht nur von dem Schlüsselwort my ab, sondern auch von der Position, in der es steht. Ehrlich gesagt fühle ich mich nicht dazu berufen, kompetente Auskunft darüber zu erteilen. Z.B. war es mir vollkommen unbekannt, der Anweisung use strict noch einen Parameter mitzugeben. --Turelion 17:44, 8. Sep. 2008 (CEST)

Du meinst das Kaptitel "Gültigkeitsbereich von Variablen"? Nunja. Klingt holprig und ist, soweit ich das beurteilen kann, noch nicht vollständig. Hauptsächlich geht es um globale Variablen. --84.190.51.115 16:23, 19. Sep. 2008 (CEST)

Angebot des MV-Verlags

Liebe Autoren,

ich habe gesehen, dass eine drucktaugliche pdf dieses Buches erstellt wurde und möchte euch auf das Angebot unseres Verlages aufmerksam machen, Wikibücher zu drucken. Schaut doch mal auf dieser Seite nach: http://de.wikibooks.org/wiki/Wikibooks:Druckausgaben/_Angebot_des_M-V-Verlages. Beste Grüße, M-v-v 13:54, 16. Jan. 2009 (CET)

Hallo MVV, schönen Dank für den Hinweis. Meiner Meinung nach ist das Perl-Buch allerdings nicht für einen Buchdruck geeignet. Wer sollte dafür Geld ausgeben, wo es doch genauere und vollständigere Internet-Tutorials gibt? Traurig, aber wahr: IMHO lohnt es sich eher, bei der Perl-Community nachzufragen: http://wiki.perl-community.de/bin/view/Wissensbasis/WebStart, die haben dort mMn mehr spezialisierte Manpower und mehr Fachkompetenz versammelt. --Turelion 18:59, 17. Jan. 2009 (CET)

Deklaration im Funktionskopf

Früher habe ich auch immer die Variablen im Kopf der Funktion deklariert. Jetzt befolge ich die drei Regeln: i. Deklaration bei erstmaliger Verwendung ii. Möglichst späte Deklaration iii. Verwendung in kleinstmöglichen Sichtbarkeitsbereich

Wie sind die Meinungen dazu?

Hallo Bernhard,

schön, daß Du hier mitarbeiten möchtest. Ich habe mal Deine Beiträge von heute gesichtet, ziemlich viel unangenehme Kleinarbeit. es ist gut, daß Du Dir die Mühe machst.

Du kannst Deine Beiträge mit ~~~~ unterzeichnen, so daß niemand nochmal nachschauen muß, welcher Beitrag von wem stammt.

Grundsätzlich würde ich der Übersichtlichkeit halber eine Variablendeklaration im Kopf bevorzugen, insbesondere bei den ständig benötigten Variablen, oder gar quasikonstanten Werten. Dort kann man in Kommentaren auch näher auf die Variablen eingehen. Bei Wegwerfvariablen ist das allerdings IMHO nicht erforderlich, z.B. bei Laufvariablen in Schleifen. Wenn die Schleifen allerdings eine bestimmte Größe überschreiten (2 oder mehr Seiten), könnte das schon wieder anders aussehen.

Mir ist nicht ganz klar, was Du mit "kleinstmöglichem Sichtbarkeitsbereich" meinst. Auch nicht, warum Du die späte Deklaration bevorzugst.

Beste Grüße, --Turelion 21:06, 10. Apr. 2009 (CEST)

Hallo Turelion

schön eine Rückmeldung zu bekommen. Ich war, bzw. bin, mir nicht sicher ob noch jemand an dem Wikibuch arbeitet.

Bzgl. der Sichtbarkeit von Variablen: Bei der Perl-Entwicklung benutze ich häufig einfache Blöcke.

{
  my $var = get_var();
  ...   # etwas mit $var tun
}

{
  my $var = get_var();
  ... # etwas anderes mit $var tun
}

anstatt

my $var;
{
  $var = get_var();
  ...   # etwas mit $var tun
}

{
  $var = get_var();
  ... # etwas anderes mit $var tun
}

Dadurch ist sichergestellt, daß der erste Block nicht mit dem zweiten Block interferieren kann.

BernhardSchmalhofer 16:23, 12. Apr. 2009 (CEST)

Webseiten und mehr

• [1] offizielle Perl-Dokumentation

konnte nicht gefunden werden. Seite nicht mehr erreichbar :-( Hab dies aktualisiert auf perldoc.perl.org  ;-) :-) @@ --62.226.239.132 01:19, 24. Jan. 2009 (CET)

Spezialvariablen

In Spezialvariablen habe ich ein paar Variablen erwähnt die in 'Vordefinierte Variablen' gehören. Ich werde das noch überarbeiten.

BernhardSchmalhofer 20:48, 18. Apr. 2009 (CEST)

Erklärung von print $_ im Abschnitt Variablen

Eben jene Erklärung fehlt. Ich persönlich bin als Neuling gerade eben doch sehr darüber gestolpert. Ein Link zum Abschnitt Spezialvariblen wäre wünschenswert. --Florian.rubach 13:23, 8. Jul. 2009 (CEST)

use diagnostics

Leider wird in sehr wenigen Büchern auf use diagnostcs hingewiesen. Ich würde stark dazu raten es einfließen zu lassen, da damit vor allem Perneulingen, aber auch Profis (es gibt oft mehrere Gründe, die zum selben oder einem ähnlichen Warning führen und nicht alle sind sehr bekannt) die Arbeit erleichtert wird.

Na ja, wäre dafür es im Zusammenhang mit Ungebungsvariablen einzuführen oder Optionsparsing, weil es irgenwann auch nervt und daher meiner Meinung nur optional im Quellcode verankert werden sollte. Gut arbeitet es ja auch als Kommandozeilenoption für perl (-Mdiagnostics).

Benutzen des Scripts: Erzeugung von SQL-Code

zumindest unter win32 Perl (ich benutze version 5.10.1006) müssen folgende Änderungen gemacht werden, um das Script zum Laufen zu bewegen: Die String-Terminatoren OUT1, OUT2, OUT3 müssen direkt am Zeilenanfang stehen, es darf KEIN white space davor sein (was unweigerlich passiert, wenn man das Script aus der Seite mit Copy/Paste erzeugt :p)

Für Neulinge nützlich fände ich zudem wenn man ein Beispiel einbaut, wie das Script zu benutzen ist: Also z.B.: meinscript.pl >entries.sql unter DOS/win32. (Für Perl Hasen sicher kein Thema, aber für den SQL-Neuling der eigentlich nur noch ein paar Datensätze zufügen will, evtl. eine Hürde :)

Hinweisen möchte ich an dieser Stelle, dass wenigstens unter mysql 5.1 das von perl erzeugte sql script NICHT läuft:

insert into VERSICHERUNGSNEHMER(VNE_NAME, VNE_VORNAME, VNE_GEBURTSDATUM, VNE_DATUM_FUEHRERSCHEIN, VNE_ORT, VNE_PLZ, VNE_STRASSE, VNE_HAUSNUMMER, VNE_EIGENER_KUNDE_J_N, VNE_VERSGESELLSCHAFT_ID) values ("Meyer", "Anton", "1925-12-11", "1991-11-12", "Essen", "56415", "Goethestr.", "58", "FALSE", "2") ;

/* SQL Error: Unknown column 'VNE_NAME' in 'field list' */

Da ich persönlich grade selbst SQL lerne, kann ich leider keine Abhilfe geben. - Wolf391 15:58, 26. Okt. 2009 (CET)

Hallo Wolf, bitte kontrolliere die Spaltennamen. Auf Einführung in SQL habe ich die Präfixe VNE usw. inzwischen entfernt; möglicherweise muss deshalb auch das Perl-Skript angepasst werden. Bitte benutze das Gleichheitszeichen nicht am Anfang einer Zeile, das gehört innerhalb von Wiki zu Überschriften. Das Gleichheitszeichen muss bei Überschriften am Anfang und am Ende einer Zeile stehen. -- Juetho 16:06, 26. Okt. 2009 (CET)

Naja, ich weiss zwar nicht was mein Beitrag unter "use Diagnostics" zu tun hat, aber wenn du meinst ...

Ich habe das Perl-Script angepaßt. In dieser Form läuft es anstandlose und erzeugt eine ca. 27mb große .sql Datei. Mein Frontend habe ich nach Abarbeiten von ca. 6000 Einträgen abgeschossen (ctrl-alt-del), weil es völlig in die Knie ging und die Abarbeitung der Datei wahrscheinlich Stunden gedauert hätte. Meiner Meinung nach ist das von Perl erzeugte SQL script VIEL zu lang, 100.000 Datensätze VERSICHERUNGSNEHMER werden nicht wirklich (?) benötigt. 3-5000 täten es doch auch. U.u. (meine Vermutung) liegt das daran dass zunächst (ca.) 100.000 INSERTS gemacht werden, die erst am Ende des Scripts 'committed' werden. Habe mir damit beholfen, dass ich mit copy/paste nur Teile dieser Datei benutzt habe.

Hier das funktionierende Perl-Script. Bitte beachten dass ein paar weitere Änderungen nötig waren neben dem oben erwähnten String-Terminator Problem (siehe meine comments im Perl Script) und den Feldnamen Änderungen:

#!/usr/bin/perl

use strict;

my @namen=("Meyer", "Müller", "Schulze", "Schneider", "Schubert", "Lehmann", 
 "Bischof", "Kretschmer", "Kirchhoff", "Schmitz", "Arndt");
my @vornamen=("Anton", "Berta", "Christoph", "Dieter", "Emil", "Fritz", "Gustav", 
 "Harald", "Ida", "Joachim", "Kunibert", "Leopold", "Martin", "Norbert", "Otto", 
 "Peter", "Quentin", "Richard", "Siegfried", "Theodor", "Ulf", "Volker", "Walter", 
 "Xaver", "Yvonne", "Zacharias");
my @orte=("Essen", "Dortmund", "Bochum", "Mülheim", "Duisburg", "Bottrop", 
 "Oberhausen", "Herne", "Witten", "Recklinghausen", "Gelsenkirchen", 
 "Castrop-Rauxel", "Hamm", "Unna", "Herten", "Gladbeck");
my $orte="";
my @strassen=("Goethestr.", "Schillerstr.", "Lessingstr.", "Badstr.", "Turmstr.", 
 "Chausseestr.", "Elisenstr.", "Poststr.", "Hafenstr.", "Seestr.", "Neue Str.", 
 "Münchener Str.", "Wiener Str.", "Berliner Str.", "Museumsstr.", "Theaterstr.", 
 "Opernplatz", "Rathausplatz", "Bahnhofstr.", "Hauptstr.", "Parkstr.", 
 "Schlossallee");
my @gesellschaften=("Zweite allgemeine Verabsicherung", "Sofortix 
 Unfallversicherung", "Buvaria Autofutsch", "Provinziell", "Vesta Blanca");
my @beschreibungen=("Standardbeschreibung Nr 502", "08/15", "Blablabla", 
 "Der andere war schuld!", "Die Ampel war schuld!", "Die Sonne war schuld!", 
 "Die Welt ist schlecht!!");
my $beschreibungen="";
my $gesellschaften=0;
my $gebdat="";
my $fdat="";
my $hnr=0;
my $eigen=""; 
foreach my $ort (@orte) {
  my $gplz=int(rand(90000))+10000;
  foreach my $strasse (@strassen) {
    my $plz=$gplz+int(rand(20));
    foreach my $name (@namen) {
      foreach my $vorname(@vornamen) {
        $gebdat=dating(80, 1907);
        $fdat=dating(80, 1927);
        $hnr=int(rand(100))+1;
#EIGENER_KUNDE_J_N ist in der SQL Datenbank definiert als CHAR(1), daher:
#statt: if(rand(2)>1) {$eigen="TRUE";} else {$eigen="FALSE";}
        if(rand(2)>1) {$eigen='J';} else {$eigen='N';}
        my $vers=int(rand(5)); 
print <<OUT1
insert into VERSICHERUNGSNEHMER(NAME, VORNAME, GEBURTSDATUM, 
DATUM_FUEHRERSCHEIN, ORT, PLZ, STRASSE, 
HAUSNUMMER, EIGENER_KUNDE_J_N, VERSGESELLSCHAFT_ID) values ("$name", 
"$vorname", "$gebdat", "$fdat", "$ort", "$plz", "$strasse", "$hnr", "$eigen", 
"$vers");
OUT1
}}}}
#Der Terminator OUT1 muss an den Zeilenanfang, es dürfen keine Leerzeichen/Tabulatoren davor sein
for(my $a=0; $a<=500; $a++)
{
  my $udat=dating(3, 2004);
  my $ort=$orte[int(rand(16))];
  my $beschreibung=$beschreibungen[int(rand(7))];
  my $shoehe=int(rand(20000000))/100;
  my $verletzte;
#VERLETZTE_J_N ist in der SQL Datenbank definiert als CHAR(1), daher:
#statt: if(rand(2)>1) {$verletzte="TRUE";} else {$verletzte="FALSE";}
  if(rand(2)>1) {$verletzte='J';} else {$verletzte='N';}
  my $mitarbeiter=int(rand(10))+1;
print <<OUT2
insert into SCHADENSFAELLE(DATUM, ORT, BESCHREIBUNG, 
SCHADENSHOEHE, VERLETZTE_J_N, MITARBEITER_ID) values 
("$udat", "$ort", "$beschreibung", $shoehe, "$verletzte", $mitarbeiter);
OUT2
}
#Der Terminator OUT2 muss an den Zeilenanfang, es dürfen keine Leerzeichen/Tabulatoren davor sein
for(my $a=1; $a<=500; $a++)
{
  my $vne=int(rand(100000))+1;
print <<OUT3
insert into ZUORD_VNE_SCF(SCHADENSFALL_ID, VERSICHERUNGSNEHMER_ID) values 
($a, $vne);
OUT3
}
#Der Terminator OUT3 muss an den Zeilenanfang, es dürfen keine Leerzeichen/Tabulatoren davor sein
sub dating
{
  my $range=$_[0];
  my $radix=$_[1];
  my $y=int(rand($range))+$radix;
  my $m=int(rand(12))+1;
  my $d=int(rand(28))+1;
  my $return=$y . '-' . $m . '-' . $d; #strings, die von Perl nicht interpoliert werden müssen, können in ' ' statt "" --Wolf391
  return $return;
}

mfg, Wolf391 17:07, 26. Okt. 2009 (CET)

"Naja, ich weiss zwar nicht was mein Beitrag unter use Diagnostics zu tun hat, aber wenn du meinst ..."

Das war ein Missverständnis meinerseits, weil du das Gleichheitszeichen am Ende der Zeile vergessen hattest; dadurch war es nicht als Überschrift eines Abschnitts erkannt worden.

Aber herzlichen Dank für deine Hinweise; ich hatte das gleiche Problem unter Verwendung bei INSERT INTO ... SELECT. Diese Hinweise werde ich auch bei Einführung in SQL: Änderung der Datenbankstruktur berücksichtigen. -- Juetho 17:57, 26. Okt. 2009 (CET)

Buchtitel

Der Unterschied zwischen Perl 5 und Perl 6 kann gerade für Anfänger schwer zu verstehen sein. Daher würde ich es gern sehen, wenn schon im Buchtitel klar gemacht wird, dass es sich hier um ein Buch zu Perl 5 handelt. Als wesentlichen Vorteil sehe ich, dass es hoffentlich bald auch ein Buch über Perl 6 geben kann.

Einen richtigen Vorschlag für den neuen Titel habe ich eigentlich auch nicht. Vielleicht "Perl5 Wikibuch". Giftnuss 23:30, 29. Nov. 2009 (CET)

Ich hätte wohl besser erstmal im Bücherregal nachgesehen. Da ist die Umbenennung bereits Realität und ein Perl 6 Buch gibt es auch schon :). Giftnuss 23:36, 29. Nov. 2009 (CET)

Zu den Dateitests

Scheint mir etwas unscharf. (-s $dateiname) kann man auch zur Unterscheidung "leere Datei" und "Dateiname nicht vorhanden" verwenden. (-s $dateiname) liefert eine Zahl zurück (bei leeren Dateien eben 0) oder undef, falls Datei nicht vorhanden. Durch Verwendung als Vergleich konvertiert man Zahl 0 auf false. Ich verwende es zur Fallunterscheidung so: my $dateiname = " "; my $groesse = 0; $groesse = (-s $dateiname); if (!defined $groesse) { # Fall "Dateiname nicht vorhanden" behandeln } else { # Fall "Dateiname vorhanden" behandeln - eventuell Fallunterscheidung "leer", "nicht leer" } lg. Helmut Wagner

Fehlendes

• "qq"