Perl ist eine ziemlich universelle und mächtige Programmiersprache, die sehr oft unter Linux im Bereich Systemadministration und Web-Programmierung eingesetzt wird. Perl wurde zu Beginn der 90'er Jahre von Larry Wall als Plattform übergreifende Sprache entwickelt und ist heute für viele Plattformen universell einsetzbar. So gibt es Portierungen für Linux, Windows und MacOSX. Perl ist damit weitaus portabler als Java, zumal Perl reiner ASCII-Code ist. Einer der großen Vorteile ist die Flexibilität von Perl bei der Programmierung. Mit PerlTk gibt es auch eine Möglichkeit, grafische Oberflächen in Perl zu erstellen. Ein weiteres, verbreitetes Einsatzgebiet, ist die CGI-Programmierung.
Leider neigt Perl-Code zumindest mancher Programmierer dazu, "write-only" zu sein (also in anderen Worten: unlesbar ).
Diese Aussage möchte ich hier nicht unkommentiert stehen lassen. Perl ist IMO eine der verständlichsten Sprachen überhaupt, weil sie die Möglichkeit gibt, den sprachlichen Ausdruck dem Problem anzupassen. Aber wie in jeder anderen Sprache gibt es auch hier Leute, die sich ausdrücken können und andere die es nicht können. Ich habe bisher bedeutend mehr Probleme bei der Analyse fremder C- oder C++-Programme gehabt als bei Perl. -- ThomasBayen
Recht hast du -- RonnyBuchmann 2002-07-18 13:01:44
Lizenz: Perl Artistic License
Vorteile von Perl
gegenüber anderen Skriptsprachen
- weit verbreitet, d.h. auf sehr vielen System standardmäßig installiert
sehr gute Dokumentation in Form von ManPages, auch bei Zusatzmodulen
- sehr umfangreiche Modulsammlung vorhanden, CPAN s.o.
Beispiel typischen Perl-Codes
# checkhelp.pl - finds configuration options that have no # corresponding section in the help file # # made by Meelis Roos (mroos@tartu.cyber.ee) # read the help file @options=split /\n/, `grep '^CONFIG' Documentation/Configure.help`; die "Can't read Documentation/Configure.help\n" if $#options == -1; #read all the files foreach $file (@ARGV) { open (FILE, $file) || die "Can't open $file: $!\n"; while (<FILE>) { # repeat until no CONFIG_* are left while (/^\s*(bool|tristate|dep_tristate|string|int|hex).*' *(.*)'.*(CONFIG_\w*)/) { $what=$3; $name=$2; s/$3//; @found = grep (/$what$/, @options); if ($#found == -1) { next if $nohelp{$what}; print "$name\n$what\n No help for $what\n\n"; $nohelp{$what}=1; } } } close (FILE); }
Na, alles klar?
wo ist das problem, ist doch verständlicher als Python, aufruf z.b. mit "find -name Config.in | xargs checkhelp.pl" -- RonnyBuchmann
So schlimm finde ich das Programm nicht, obwohl einige seltsame Sachen darin sind...
Weitere Codeschnipsel findet man unter den PerlEinzeilern.
Warum sind in Perl beide Wege richtig?
Ich möchte meine Behauptung mal an einem Teil des obigen Programms belegen. Die Philosophie von Perl ist TMTOWTDI (There's more than one way to do it). Das bedeutet, wer ein schlechter Programmierer ist, kann auch leicht schlecht lesbaren Code erzeugen. Andere Sprachen (wie z.B. C++ oder Java) neigen hingegen dazu, wunderschön anzusehende und zu lesende Programme zu erzeugen, die trotzdem keiner versteht (und schlimmer noch: die gar nicht erst jemand schreibt). Ich nehme mal den folgenden Codeabschnitt:
# read the help file @options=split /\n/, `grep '^CONFIG' Documentation/Configure.help`; die "Can't read Documentation/Configure.help\n" if $#options == -1;
Was möchte uns der Autor damit sagen?!?
Zeile 2 ist etwas unübersichtlich für nicht-Perler. Allerdings ist der hintere Teil keinesfalls ein Perl-Befehl, sondern ein Shell-Aufruf des grep-Befehls. Der Programmautor hat - angesichts der Tatsache, daß es ein Perl-internes grep gibt, definitiv eine Bash-Vorgeschichte. Das "split", um die einzelnen Zeilen zu extrahieren, ist IMHO nicht die richtige Semantik, um auszudrücken, was wir tun. Wir wollen nichts splitten, sondern wir wollen was einlesen, das kann (und sollte) man anders ausdrücken.
Zeile 3: Die Abfrage $#... == -1 steht weiter unten im Quelltext nochmal. So habe ich das noch nicht gesehen. Scheinbar hat der Autor auch C-Erfahrung (oder Basic?) Kein Mensch will hier was mit Minus Eins wissen. Die Frage ist: Gibts Optionen oder nicht?
Jetzt mal so, wie ich das schreiben würde:
open FILE, 'Documentation/Configure.help'; @options=grep(/^CONFIG/, (<FILE>)) or die "Can't read Documentation/Configure.help\n";
So haben wir das Problem klar in seine Schritte zerlegt und jeweils eine Zeile für einen Denkschritt genommen. Das Ganze ist direkt lesbar und bedarf eigentlich keiner Kommentierung.
- Finde ich nicht so schön, weil es ziemlich "hinterrücks" ist (Warum steht da "die" nach "grep"?, Was ist das für ein komischer Aufruf von Grep, mit dem Filehandle dahinter?) - Schöner, der Reihe nach, und ohne Shell-Erbstücke, wäre es so:
open FILE, '<Domentation/Configure.help' or die "Kann Datei nicht öffnen: $!\n"; while (<FILE>){ # Wenn beim Lesen keine Variable angegeben wird, wird die Zeile in $_ abgelegt. # $_ ist dann die Default-Variable, auf die die Match-Operation in der folgenden # if-Anweisung angewendet wird. if (/^CONFIG/){ push @config, $_; } }
Aber wie üblich, TIMTOWTDI. Ich habe schon Perlscripts gesehen, die praktisch nur für die Ablaufsteuerung der darin enthaltenen Shell-Aufrufe dienten. (MartinSchmitt, 2024-10-31 23:51:47)
Zusammenfassend kann man sagen, daß der Autor, obwohl er sich nicht perfekt ausgedrückt hat, trotzdem ein laufendes Programm hinbekommen hat. Dabei hat er seine Bash- und C- Erfahrungen verwerten können. Gerade die Kombination mit Bash-Befehlen ist zwar nicht sehr konsistent, erleichtert aber ungemein die Weiterverwendung von bestehendem Wissen über den Unix-Baukasten. Das Programm ist von jemandem mit mittelmäßigen Unix-Kenntnissen (über grep und Regexes) lesbar. Außerdem ist (in beiden Lösungen) ein Problem, das drei Denkschritte enthält, in drei Zeilen gelöst worden. Ob z.B. eine Java-Lösung, die erstmal eine eigene Klasse für das Problem und alle Variablen deklariert hätte, das so übersichtlich gemacht hätte, bleibt dem Leser überlassen... -- ThomasBayen
Ich fasse eher zusammen, dass es in Perl so viele Lösungswege wie Programmierer gibt, möglicherweise mehr. Es scheint geradezu unmöglich zu sein, alle Perl-Konstrukte zu kennen und dementsprechend zu interpretieren. Mit ist zum Beispiel neu, dass ein Array eine negative Länge haben kann. Besonders dicht am Problem ist diese Formulierung auch nicht gerade. Für Ronnys Beispiel möchte ich noch die Alternative
while(<>) {
an Stelle von
foreach $file (@ARGV) { open (FILE, $file) || die "Can't open $file: $!\n"; while (<FILE>) {
beisteuern. Viel praktischer, aber ist trotzdem noch jedem klar, was es macht?
ja innerhalb von 30sec (inkl verstehen und für schlecht befinden) -> man perlfunc oder man perlop -- RonnyBuchmann 2002-08-04 19:36:32
info gcc hilft mir da wesentlich weniger
- Du, die Erfahrung lehrt, dass ich, obwohl ich die Sprache nicht mag und ihr aus dem Weg gehe, mehr Perl-Konstrukte kenne als meine Kollegen. Ich kann deren Code lesen (obwohl es weh tut), umgekehrt klappt es nicht. Sollte uns das nicht zu denken geben?
Perl-Code
Fragen zu Perl
Wie lese ich mit Perl den TOC einer Audio-CD aus?
http://search.cpan.org/author/DOUGM/Audio-CD-0.04/CD.pm