perl Datei Zeile suchen und weitere anfügen

[misterf]

Hallo zusammen,
ich möchte in einer Datei an einer bestimmten Stelle 2 weitere Zeilen einfügen.
es geht um ServerAliase in der apache-vhost.conf.

Ich hatte es mir so gedacht das mir das script den ServerAlias der domain ausliest, darunter dann zwei neue Zeilen für einen neuen SeverAlias einfügt.

Eingelesen habe ich die Datei und die Zeile mit dem ServerAlias der Domain finde ich auch.
Nur hänge ich etwas daran wie es jetzt weitergeht.
Ich dachte mir das ich die ersten Zeilen der Datei inkl. der gesuchten Zeile in ein Array1 lese. Dann alle folgenden zeilen in ein Array2.
Nun eine neue Datei schreiben in der ich als erstes array1 schreibe. Dann füge ich die neuen Serveraliase an und als letzten Schritt füge ich Array2 an.

Nur scheitert dieser Gedanke etwas an der Umsetztung

Hoffe mir kann dabei jemand helfen.

Gruss misterf

[Sid Burn]

Du öffnest die vorhande config datei zum lesen, und erstellt eine neue datei zum schreiben.

dann gehst du die config datei zeilenweise durch. änderst die zeilen etc. und schreibst es in die neue datei. Wenn deine bedingung stimmt, schreibst du eben zwei zeilen direkt in die neue datei.

Wenn du die dateien bearbeitet hast, schließt du beide dateien, löscht die alte config datei, und renamest deine neue erstellt datei über die alte.

Optimal ist es wenn du für die neue Datei eine Temp Datei erzeugst. Dafür gibt es das Core Modul "File::Temp" damit du es auch "sicher" machst.



Ein anderer Weg ist du nutzt das Core Modul "Tie::File". Das stellt dir dann ein Array zur verfügung das deine datei darstellt. Daher jede änderung am array spiegelt sich automatisch auf deine echte datei ab.

Löscht du einträge aus dem array, löscht du zeilen aus der Datei etc. Für kleine Config dateien ist das okay. Für große Dateien (Gigabyte oder mehrere Megabyte) sollte man das nicht mehr nutzen.

[jan61]

Moin,

wenns nicht gleich Perl sein muss (für so einfache Sachen gibt es doch genug Shell-Mittelchen ;-), dann schau Dir mal diesen Thread an: http://www.mrunix.de/forums/showthread.php?t=60406

Das kannst Du leicht abgewandelt für Dein Problem benutzen:

INS_VAR='\
Zeile1\
Zeile2'
sed -r -i 's|(DerAlias)|\1'"$INS_VAR"'|' apache-vhost.conf

Mit der -i-Option führt sed gleich eine InPlace-Ersetzung durch.

Jan

[Sid Burn]

Moin,
wenns nicht gleich Perl sein muss (für so einfache Sachen gibt es doch genug Shell-Mittelchen ;-)

Man kann Perl auch von der Shell aus nutzen.

perl -i -pe 's|(DerAlias)|$1\nZeile1\nZeile2|' apache-vhost.conf

Schöner als dein sed Kommando, und wenn man "-i.bak" nutzt wird gleich noch eine Kopie der alten datei mit dateiendung .bak angelegt. Für den Fall der Fälle...

Ansonsten hängt es vom genauen umfeld ab wovon der Threadersteller ja nichts schreibt ob eine Shell Lösung überhaupt in Frage kommt.

[jan61]

Moin,

Man kann Perl auch von der Shell aus nutzen.

Das ist mir schon klar ;-) Was ich meinte: Warum eine ausgewachsene Programmiersprache hernehmen, wenn es auch mit einfacheren Mitteln geht? Perl ist ja nun nicht gerade als schlanker Ressourcen-Schoner bekannt.

perl -i -pe 's|(DerAlias)|$1\nZeile1\nZeile2|' apache-vhost.conf

Schöner als dein sed Kommando, und wenn man "-i.bak" nutzt wird gleich noch eine Kopie der alten datei mit dateiendung .bak angelegt. Für den Fall der Fälle...

Naja, das ist Ansichtssache. Ich kann auch den Inhalt der mehrzeiligen Variable direkt in den sed klatschen. Und ein Backup anlegen kann der auch - mit der gleichen Syntax wie Perl.

Apropos: Mir ist aufgefallen, dass ich die Klammern für den Puffer vergessen habe - muss ich gleich noch ändern.

Jan

[Sid Burn]

Moin,
Das ist mir schon klar ;-) Was ich meinte: Warum eine ausgewachsene Programmiersprache hernehmen, wenn es auch mit einfacheren Mitteln geht?

Was ist daran kompliziert wenn es so wie du sagtest sogar die gleiche Parameter sind?

Perl ist ja nun nicht gerade als schlanker Ressourcen-Schoner bekannt.

Hast du noch ein 8086 mit 32K RAM das dies eine Rolle spielt?

Ansonsten ist das auch nicht so pauschal aussagbar. Wenn es ein kompliziertes Skript ist, ist es ressourcenschonender es komplett in Perl zu machen anstatt evtl. hunderte von prozessesen zu starten die so ein großes Shell Skript im laufe seiner Zeit aufruft.

Und wenn er die Aufgabe bereits in einem größern Perl Skript einfügen möchte ist es auch unsinnig generell auf "sed" zurück zu greifen oder nochmals perl zu starten.

Wie es genau ist weiß nur der Threadstarter. Aber gab er ja einen Hinweis darauf und fragte "explizit" wie man es in Perl macht, und er fragte nicht wie man es generell macht, oder in sed.

[msi]

sed und awk haben eingetlich ausgedient. Mit perl steht eine weit aus mächtigere und einfach zu Bedienendere Software für bequeme Stringverarbeitung zur Verfügung.

Jedem Anfänger würde ich abraten awk und sed zu lernen und stattdessen perl empfehlen

[jan61]

Moin,

sed und awk haben eingetlich ausgedient. Mit perl steht eine weit aus mächtigere und einfach zu Bedienendere Software für bequeme Stringverarbeitung zur Verfügung.

Jedem Anfänger würde ich abraten awk und sed zu lernen und stattdessen perl empfehlen

über die Aussage hab ich doch schon mal Tränen gelacht. Um es nochmal deutlich zu sagen: Es gibt nach wie vor Systeme, auf denen Perl nicht zur Verfügung steht.

Und außerdem: Ich habe schon mehrmals gleiche Aufgaben in awk und Perl realisiert, und wenn es nicht gerade um Sachen wie Sortieren am Ende der Eingabe (oder eben komplexe Geschichten, die mit awk nicht mehr sinnvoll zu realisieren waren) ging, war awk in der Regel deutlich schneller als Perl.

Auch in Zeiten von xGB an RAM und GHz-schnellen Prozessoren ist es meiner Meinung nach unverantwortlich, sich nicht um schonenden Umgang mit Systemressourcen zu scheren. Man ist mit seinen Programmen meist nicht allein auf dem System.

Ich will nicht gegen Perl argumentieren (ich benutze es selbst häufig und es gibt genug Beispiele, wo sed und Co. nicht mehr reichen), aber bei jedem Kleinkram mit einem Bohrhammer wie Perl zuzuschlagen, ist für mich der falsche Weg.

Jan

[Sid Burn]

über die Aussage hab ich doch schon mal Tränen gelacht. Um es nochmal deutlich zu sagen: Es gibt nach wie vor Systeme, auf denen Perl nicht zur Verfügung steht.

Hmm, auf welchen denn?

Und nur so nebenbei. Die ganzen Shell Tools sind nicht Standarisiert. Okay POSIX Standard gibt es schon. Aber nur weil du ein Shell Skript schreibst bedeutet es nicht das es automatisch auch so auf jeder Maschiene läuft wo eine Shell installiert ist und die entsprechenden Programme. Wenn du Bash Skripten lernst bringt dich das auch nicht weiter wenn auf dem Zielsystem kein bash installiert ist. Ist z.B. Standardmäßig nicht auf OpenBSD. Klar du kannst es installieren, du kannst aber auch einfach Perl installieren.

Da hast du mit Perl aber eine deutlich größere Portabilität als wenn du Shell Skripten lernst. Teilweise gibt es z.B. manche Kommandoswitche auf manchen BSD oder UNIX Systemen gar nicht. Die GNU Tools erweitern dort ja schon ziemlich.

Zum anderen können Tools ihre ausgabe ebenfalls anders ausgeben. Und manche Tools wie z.B. "df" geben schon auf unterschiedlichen Linux Distributionen Daten anders aus.

Für ein Shell Skript das primär nur Daten von anderen Programmen liest und versucht zu parsen ist das aber nicht gerade optimal. Generell ist diese art der Programmierung ziemlich Fehleranfällig.

Und außerdem: Ich habe schon mehrmals gleiche Aufgaben in awk und Perl realisiert, und wenn es nicht gerade um Sachen wie Sortieren am Ende der Eingabe (oder eben komplexe Geschichten, die mit awk nicht mehr sinnvoll zu realisieren waren) ging, war awk in der Regel deutlich schneller als Perl.

Für eine sache die man einmal aufruft wie in diesem Beispiel hier spielt Performance wohl wenig eine Rolle.

Ansonsten kenne ich es nur umgekehrt, beispiele wo Perl schneller war, auch als sed. Ansonsten hängt das aber wie du ja schon sagtest immer von Fall zu Fall ab, aber auch wie man es Programmiert.

Auch in Zeiten von xGB an RAM und GHz-schnellen Prozessoren ist es meiner Meinung nach unverantwortlich, sich nicht um schonenden Umgang mit Systemressourcen zu scheren. Man ist mit seinen Programmen meist nicht allein auf dem System.

Da das Programm sich sofort beendet nachdem es seine Aufgabe erfüllt hat, und alle Ressourcen wieder frei gibt, spielt das keine Rolle.

Ansonsten sage ich ja auch nicht das man Ressourcen verbrauchen soll wie man es möchte. Aber das Perl so viel Ressourcen benötigt stimmt nun auch nicht.

Und je komplexer etwas wird, desto mehr gewinnt Perl eher das Ressourcenschonende. Shell Skripte an sich bestehen ja nur durch eine aneinanderkettung, und ausführen von Befehlen. Hast du eine schleife die 1000en mal durchlaufen wird und dort ein "sed" programm aufgerufen wird, wird auch 1000 mal sed gestartet und immer wieder neu geforkt.

Perl hingegen startet ein Prozess und gut ist, kein ewiges neu forken (sofern man es natürlich nicht so programmiert) das schond nicht nur RAM sondern auch CPU Zeit.

Und wenn man wirklich so knapp bemessen ist und bei einen Afruf von Perl der Server anfängt zu swappen, dann hat man wohl eher ein ganz anderes Problem. Dann sollte man sich so oder so um einen besser ausgestatten Server kümmern.

Ich will nicht gegen Perl argumentieren (ich benutze es selbst häufig und es gibt genug Beispiele, wo sed und Co. nicht mehr reichen), aber bei jedem Kleinkram mit einem Bohrhammer wie Perl zuzuschlagen, ist für mich der falsche Weg.

Okay dann mal genauer zum Borhammer. Wenn ich einfach nur "perl -wle 'sleep 100'" eintippe und den RAM Verbrauch messe kommt folgendes dabei heraus:

VIRT: 6388
RES: 1312

Ein simples shellskript das nur "#!/bin/bash" als shebang hat und ein "sleep 100" aufruft. Das ganze führt dazu das bash nochmals gestartet wird.

bash selber:
VIRT: 6060
RES: 1410

sleep:
VIRT: 4716
RES: 504



Wenn wir also VIRT zusammenrechnen was alles beinhaltet haben wie bei Perl das insgesammt 6388 verbraucht. Die Skriptlösung verbraucht 10776 (alle angaben in Bytes).

Und wenn ich den RES wert nehme was den CODE + DATA Segment ist komme ich auf 1312 vs 1914.

Der Verbrauch ist also weniger, selbst bei einem absolut simplen programm. Nur wird der RAM verbrauch bei perl auch nicht so ins extreme ansteigen wie bei der bash. Dort wird wie bereits gesagt für jeden prozess geforkt und muss wieder neu alloziert werden was deutlich mehr Ressourcen (CPU) verbrät als alles andere.

Ansonsten solltest du ja auch wissen das bei Linux/Unix System generell Libraries geshared werden. Rufe ich also einmal Perl auf verbraucht es zwar Speicher. Aber der nächste aufruf von Perl würde der Perl Interpreter selber wohl geshared sein.

Zu sagen das Perl ein borhammer ist kann ich hier nicht zustimmen. Und wenn du es gleich von anfang an nutzt kannst du es auch entsprechend erweitern und ausbauen.

Selbst bei Shell Skripten die wirklich klein sind und so in 20-30 Zeilen Bereich gehen denke ich mir oft. Mein Gott selbst soetwas simples ist deutlich einfacher und würde mit Perl so schnell gehen. Stattdessen wird dann krampfhaft versucht die Shell zu nutzen, bis man dann irgendwann merkt das es gar nicht mehr geht, und dann muss man das geschriebene evtl. gleich nochmal komplett neu schreiben weil man es evtl. auf Perl/Python/Ruby oder sonstetwas portiert.

Ich würde jemanden auch nicht mehr empfehlen das Shell Skripten zu lernen, sondern lieber eine der genannten Programmiersprachen. Diese sind meist deutlich mächtiger/einfacher und konsistenter. Durch ein Modulsystem muss man nicht immer wieder das Rad neu erfinden. Dadurch sind viele aufgaben leichter und schneller erledigt. Klar Grundlagen der Shell, etwas Pipen, 2-3 Kommandos mal schnell zusammenpipen sollte man können. Wenn es aber um irgendein art von Logik geht würde ich dafür auch kein Shell Skripten mehr empfehlen.

Wer es sich selber antun möchte kann es natürlich trotzdem weiterhin machen.

[jan61]

Moin,

embedded Systeme z. B.? Kommerzielle Unix-Systeme? Ab und zu trifft man auch dort auf Perl, aber man kann sich nicht darauf verlassen. Auf das Vorhandensein einer Shell schon.

Das Gleiche gilt übrigens z. B. für den Boot-Prozess eines Unix- oder Linux-Systems (schon mal versucht, Dein Allzweckwerkzeug Perl einzusetzen, wenn /usr nicht gemountet werden konnte?) Mal versucht, in dem Fall die /etc/fstab zu reparieren ("which vim": /usr/bin/vim)?

Du gehst in Deinen Betrachtungen immer davon aus, dass ein Shell-Script nur dazu da ist, pausenlos externe Programme aufzurufen. Das ist natürlich Unsinn - genau das versucht man z. B. beim Einsatz von sed, grep oder awk ja zu vermeiden - man muss sich nur damit etwas gründlicher befassen. Deine Zeitmessung mit sleep hat nur eins gezeigt: Pausenlos neue Prozesse zu forken ist teuer.

Natürlich gibt es Unterschiede zwischen den Shells - genauso wie es Unterschiede zwischen Perl, Python, Ruby, Tcl ... gibt - nur sind sie zwischen den Shells längst nicht so gravierend wie zwischen den Scriptsprachen. Portable Programmierung verlangt immer Kompromisse und Nachdenken, auch in Perl (siehe z. B. "perldoc -f unlink" oder "perldoc -f mkdir").

Wenn es sich für Dich nicht mehr lohnt, sich mit der Shell (und wie ich Dich verstanden habe, mit den restlichen unter Unix/Linux vorhandenen Kommandozeilen-Tools? Wo die doch so gar nicht kompatibel zueinander sind?) zu befassen, dann wirfst Du 90% der Hilfsmittel weg, die Dir jedes Unix-artige System von Haus aus liefert. Wenn Du damit klarkommst, dann ist das Deine Sache. Aber hier dazu aufzurufen, das nicht mehr zu lernen, provoziert eine Generation von DAUs, die sich nicht mehr in ihrem System zurechtfindet.

Zum Thema Fehleranfälligkeit: 3-dimensionale Sauerkrautprogramme kann ich mit allen Mitteln zusammenschustern, egal ob Perl oder Shell oder was anderes. Gerade Perl durch seine kompakte und oft kontextsensitive Syntax ist ein 1A-Anwärter dafür. Ohne "-w"-Switch bzw. "use strict; use warnings;" kriegst Du doch z. B. gar nicht mit, wenn Du Dich bei Variablennamen verschreibst und wunderst Dich. Das Problem sitzt immer 80 cm vor dem Bildschirm.

Jan

EDIT: Ach ja - zum Thema Ressourcenverbrauch: Ich habe mal auf einem Solaris-System (wo das Erzeugen von Prozessen noch teurer ist als unter Linux) ein Shell-Script zum Auswerten von ein paar Millionen Datensätzen durch ein Perl-Script ersetzt (Die Daten mussten aus ein paar Hundert Dateien zuammengesucht und dann noch insgesamt korreliert werden). Die Performance lag um Potenzen höher - allerdings konnte ich das Script nicht mehr im normalen Tagesbetrieb laufenlassen, weil es 4 GB RAM + 90% Systemlast innerhalb von Minuten für sich beanspruchte.

[Sid Burn]

embedded Systeme z. B.? Kommerzielle Unix-Systeme? Ab und zu trifft man auch dort auf Perl, aber man kann sich nicht darauf verlassen. Auf das Vorhandensein einer Shell schon.

Aber nicht auf das vorhandensein der ganzen Tools die du nutzt mit all den Optionen die du auf anderen Systemen nutzt. Das du solche Tools hast ist die Gewissheit genau so hoch als wenn dort Perl installiert ist.

Das Gleiche gilt übrigens z. B. für den Boot-Prozess eines Unix- oder Linux-Systems (schon mal versucht, Dein Allzweckwerkzeug Perl einzusetzen, wenn /usr nicht gemountet werden konnte?) Mal versucht, in dem Fall die /etc/fstab zu reparieren ("which vim": /usr/bin/vim)?

...

Natürlich gibt es Unterschiede zwischen den Shells - genauso wie es Unterschiede zwischen Perl, Python, Ruby, Tcl ... gibt - nur sind sie zwischen den Shells längst nicht so gravierend wie zwischen den Scriptsprachen. Portable Programmierung verlangt immer Kompromisse und Nachdenken, auch in Perl (siehe z. B. "perldoc -f unlink" oder "perldoc -f mkdir").

Wenn es sich für Dich nicht mehr lohnt, sich mit der Shell (und wie ich Dich verstanden habe, mit den restlichen unter Unix/Linux vorhandenen Kommandozeilen-Tools? Wo die doch so gar nicht kompatibel zueinander sind?) zu befassen, dann wirfst Du 90% der Hilfsmittel weg, die Dir jedes Unix-artige System von Haus aus liefert. Wenn Du damit klarkommst, dann ist das Deine Sache. Aber hier dazu aufzurufen, das nicht mehr zu lernen, provoziert eine Generation von DAUs, die sich nicht mehr in ihrem System zurechtfindet.

Hier redest du irgendwie komplett am Thema vorbei. Keiner sagte (auch ich nicht) das man sich nicht mit Shell Programmen und den normalen Tools nicht auseinander setzen sollte. Das sagte ich defentiv nicht.

Ich schrieb ja auch das eine normale nutzung üblich ist. Ich arbeite auch primär auf der Shell. Nutze SSH Shell Programme, Cursed Based Programme etc. pp. Das was ich sagte ist wenn man anfängt mit "Shell Programmierung". Und die Programmierung hat erstmal gar nichts mit einer nutzung zu tun.

Wenn ich die /etc/fstab fixen muss dann mache ich das mit vim, nano, mcedit oder was sonst so installiert ist, und nutze natürlich kein perl. Perl ist kein Editor warum sollte ich es damit erledigen?

Aber wenn ich anfange zu programmieren und sachen automatisieren möchte dann nutze ich Perl, und es macht mehr Sinn Perl zu nutzen.

Du gehst in Deinen Betrachtungen immer davon aus, dass ein Shell-Script nur dazu da ist, pausenlos externe Programme aufzurufen. Das ist natürlich Unsinn - genau das versucht man z. B. beim Einsatz von sed, grep oder awk ja zu vermeiden - man muss sich nur damit etwas gründlicher befassen. Deine Zeitmessung mit sleep hat nur eins gezeigt: Pausenlos neue Prozesse zu forken ist teuer.

Der Einsatz von Perl vermeidet das Forken von immer neuen Prozessen komplett. 1 Prozess wird gestartet und das war es. Und es liefert dir vernünftigen umgangen mit variablen (datenstrukturen). Module für Sachen die schon jemand gelöst hat. Alle Tools die du bei Shell Skripten nutzt von sed, grep, awk hast du bereits in Perl eingebaut. Der Vorteil liegt eigentlich schon klar auf der Hand.

Ansonsten erreichst du ein nicht ständiges neu forken bei Shell Skripten nur wenn dein komplettes Programm aus einer Pipe besteht. Wie ich auch sagte sehe ich kein problem mal 2-3 kommandos aneinanderzuhängen. head,tail,grep und wie die ganzen kommandos sonst noch heißen nutze ich auch. Aber ich mache damit keine Programmierung mit Logik.

Sprich wo ich sachen abfragen muss. if bedingungen, while schleifen etc. pp. und hast du soetwas ist es in Perl in der Regel einfacher und du forkst nicht dauernd wie bei der verwendung der Shell.

Ansonsten hat das Beispiel mit dem sleep nicht gezeigt das ständigen forken nachteilig ist. Ganz im gegenteil. Den durch sleep wurden die programme einmal gestartet und liefen erstmal. Und nur die grundvorraussetzung "bash + sleep" hat bereits mehr speicher verbrauch als ein einzelner perl interpreter. Und Perl bietet da doch etwas mehr funktionalität als ein bash + sleep.

Es zeigt also das Perl nichtmal ansatzweise der Bohrhammer ist so wie du es willst, wenn dann sind es eher Shell Skripte.

Das passt auch logisch besser. "grep" hat eine Regex Engine? Gut dann ist eine Regex Engine in "grep" eingebaut. sed läuft auch mit einer Regex Engine? Hey dann muss schon wieder eine regex engine in sed eingebaut werden. Wahrscheinlich werden es nichtmal die selben sein. Selbst die Bash versteht eine art von regexen und muss das ganze für sich implementieren. Bei Perl hingegen gibt es einmal eine implementierung, und sie werden von allen eingebauten befehlen genutzt. Nicht jedes tool kocht sein eigenes süpchen. Das minimiert auch Speicherverbrauch.

Natürlich gibt es das konzept der shared memorys und bibliotheken etc. wo das dann wieder keine rolle spielt. aber bei den grundtools wirst du ja selber wissen das diese alle statisch gelinkt sind, damit sie im fehlerfall auch funktionieren auch wenn die bibliotheken fehlen. Das erhöht eher den Speicherbedarf.

Zum Thema Fehleranfälligkeit: 3-dimensionale Sauerkrautprogramme kann ich mit allen Mitteln zusammenschustern, egal ob Perl oder Shell oder was anderes. Gerade Perl durch seine kompakte und oft kontextsensitive Syntax ist ein 1A-Anwärter dafür. Ohne "-w"-Switch bzw. "use strict; use warnings;" kriegst Du doch z. B. gar nicht mit, wenn Du Dich bei Variablennamen verschreibst und wunderst Dich. Das Problem sitzt immer 80 cm vor dem Bildschirm.

Deswegen nutzt man ja auch "use warnings" und "use strict" um fehler zu vermeiden. Beim Shell Skripten hast du keine Möglichkeit dir eine überprüfung einbauen zu lassen wenn du dich bei einer variable vertippst, selbst wenn du es wolltest. Klar du kannst es "strict" und "warnings" nicht nutzen dann degradierst du dich auf Shell Skripten herunter. Daher auch wenn du es nicht nutzt geht dir nichts verloren was du irgendwie bei der shell programmierung hättest.

Ansonsten sind Tools dazu da einem benutzer zu helfen und sich nicht in den weg zu stellen. Den Fehler immer nur auf dem benutzer zu schieben ist also falsch.

Klar ist der Benutzer schuld wenn er sich vertippt, aber ein System das soetwas erkennt ist besser als ein System das soetwas nicht erkennt und es durchgehen lässt. (Bei Perl 6 sind "strict" und "warnings" übrigens default an).

Ansonsten sprach ich von Fehleranfälligkeit nicht von Bugs. Den Shell Skripten besteht im wesentlichen darin die ausgabe von anderen programmen zu lesen und weiter zu verarbeiten.

Und das ist das problematische. Den die ausgabe selber kann sich unterscheiden. Sie kann sich schon bei unterschiedlichen Distribution unterscheiden, und bei anderen Platformen sowieso. Oder auch schon bei unterschiedlichen versionen. Eingebaute Befehle in Perl machen aber egal auf jeden System das gleiche. Sie geben mir das gleiche zurück und machen das gleiche auf den unterschiedlichen Systemen.

Alleine Regexe sind schon ein Punkt. Die Regexe unterscheiden sich in syntax und Funktionalität schon in den unterschiedlichen tools voneinander. Die gleiche Regex kann sogar schlicht bei einem anderen Tool zu einem komplett anderen Match führen. Sowas ist nicht gerade förderlich.

EDIT: Ach ja - zum Thema Ressourcenverbrauch: Ich habe mal auf einem Solaris-System (wo das Erzeugen von Prozessen noch teurer ist als unter Linux) ein Shell-Script zum Auswerten von ein paar Millionen Datensätzen durch ein Perl-Script ersetzt (Die Daten mussten aus ein paar Hundert Dateien zuammengesucht und dann noch insgesamt korreliert werden). Die Performance lag um Potenzen höher - allerdings konnte ich das Script nicht mehr im normalen Tagesbetrieb laufenlassen, weil es 4 GB RAM + 90% Systemlast innerhalb von Minuten für sich beanspruchte.

Wieviel RAM es verbraucht hängt erstmal davon ab wie es programmiert wurde. Von daher ist dein text eigentlich schon total albern.

Das Programm verbraucht nicht grundlegend 4GiB nur weil es in Perl geschrieben wurde. Wenn du in der Programmierung vorsiehst alles in variablen,arrays,hashes packst dann ist klar das etwas viel ram verbraucht.

Machst du das gleich in einem Shell Skript und speicherst alles in Umgebungsvariablen hast du das gleiche Ergebnis.

Und Systemressourcen zu verschwenden ist auch nicht schwer. 100% Systemlast und 100% Memory verbrauch schaffe ich sogar in einem einzeiler:
"perl -wle 'while(1){$a.='y'x1024}"
Das läuft solange bis alle Ressourcen verbraucht sind und mit einem "Out of memory" abbricht.

Eine Aussage wie "Ich hab da ein Skript das verbraucht aber viel Speicher und CPU zeit" ist daher ziemlich nichts aussagend. Möchtest du genau bewerten müsstest du die gleiche aufgabe in einem Shell Skripte und als Perl Programm jeweils implementieren und vergleichen.

[jan61]

Moin,

ich gebs auf ...

Aber nicht auf das vorhandensein der ganzen Tools die du nutzt mit all den Optionen die du auf anderen Systemen nutzt. Das du solche Tools hast ist die Gewissheit genau so hoch als wenn dort Perl installiert ist.

Nein, ist es nicht. Die üblichen Tools (u. a. sed, awk, grep) wirst Du immer finden. Perl nicht.

Wenn ich die /etc/fstab fixen muss dann mache ich das mit vim, nano, mcedit oder was sonst so installiert ist, und nutze natürlich kein perl. Perl ist kein Editor warum sollte ich es damit erledigen?

z. B. wenn - wie ich ja beschrieben hatte - kein Editor zur Verfügung steht? Ich wollte damit auch nur eine der Möglichkeiten andeuten, in denen Dir auch auf einem halbwegs aktuellen System kein Perl zur Verfügung steht. Wenn Du Dich in Deinen Kenntnissen ausschließlich auf Perl verlässt, dann bist Du in solchen Situationen erschossen. Eine andere Situation: Wie willst Du die - bis heute üblichen - Init-Prozesse auf einem Unix-System verstehen, wenn Du nicht mal die zahlreichen rc-Scripts verstehen kannst?

Der Einsatz von Perl vermeidet das Forken von immer neuen Prozessen komplett. 1 Prozess wird gestartet und das war es. Und es liefert dir vernünftigen umgangen mit variablen (datenstrukturen). Module für Sachen die schon jemand gelöst hat. Alle Tools die du bei Shell Skripten nutzt von sed, grep, awk hast du bereits in Perl eingebaut. Der Vorteil liegt eigentlich schon klar auf der Hand.

Ja, und bei Nutzung von sed oder awk mache ich genau das Gleiche: Ich nutze die eingebauten Möglichkeiten dieser Tools - alles ohne Forks. Das auslösende Code-Beispiel in sed war genau so eine Variante. Wo lag da der Vorteil von Perl auf der Hand?

Sprich wo ich sachen abfragen muss. if bedingungen, while schleifen etc. pp. und hast du soetwas ist es in Perl in der Regel einfacher und du forkst nicht dauernd wie bei der verwendung der Shell.

Hä? if, while, case usw. sind Shell-Builtins, wo forke ich denn da??? Für den switch gibt es nebenbei gesagt erst in Perl6 eine vernünftige Alternative.

Ansonsten hat das Beispiel mit dem sleep nicht gezeigt das ständigen forken nachteilig ist. Ganz im gegenteil. Den durch sleep wurden die programme einmal gestartet und liefen erstmal. Und nur die grundvorraussetzung "bash + sleep" hat bereits mehr speicher verbrauch als ein einzelner perl interpreter. Und Perl bietet da doch etwas mehr funktionalität als ein bash + sleep.

jan@jack:~> which sleep
/bin/sleep

Das passt auch logisch besser. "grep" hat eine Regex Engine? Gut dann ist eine Regex Engine in "grep" eingebaut. sed läuft auch mit einer Regex Engine? Hey dann muss schon wieder eine regex engine in sed eingebaut werden. Wahrscheinlich werden es nichtmal die selben sein.

Lies erstmal die man-Pages, ehe Du sowas schreibst. Alle Tools, die Regex nutzen, verstehen die gleiche Syntax (basic regex: sed, grep; extended regex: awk, sed -r, grep -E). Alle Regex sind POSIX.2 kompatibel. Ein basic regex pattern, das von einem Tool verstanden wird, wird von allen anderen haargenauso interpretiert, bei Extended Regex ist es das Gleiche.

Wenn Du in die Falle basic vs. extended regex tappst, dann liegt das eben genau daran, dass Du ja keine Zeit mit dem Erlernen dieser Werkzeuge "verschwenden" willst.

Selbst die Bash versteht eine art von regexen und muss das ganze für sich implementieren.

Aha - das ist mir neu. Mit welchen bash-Builtins kannst Du denn Regex verarbeiten?

Meinst Du Parameter-Substitution wie in ${parameter/pattern/string}? Das nennt sich "pathname expansion", hat überhaupt nichts mit Regex zu tun und ist in Perl genauso unterschiedlich zu behandeln ("perldoc -f glob").

Klar ist der Benutzer schuld wenn er sich vertippt, aber ein System das soetwas erkennt ist besser als ein System das soetwas nicht erkennt und es durchgehen lässt. (Bei Perl 6 sind "strict" und "warnings" übrigens default an).

Naja, Perl6 ist immer noch nicht released, bisher leben wir mit Perl5. Du willst Unterstützung beim Programmieren in der Shell? Sieh Dir mal im Bash-Manual den Abschnitt über "set" an (z. B. "set -u"). Ach richtig, es lohnt sich ja nicht mehr, sich damit zu befassen.

Ansonsten sprach ich von Fehleranfälligkeit nicht von Bugs. Den Shell Skripten besteht im wesentlichen darin die ausgabe von anderen programmen zu lesen und weiter zu verarbeiten.

Ich habs schon mal geschrieben: Das ist Unsinn. Deine Definition eines Shell-Scripts hat was von einem Tunnelblick. Und Fehleranfälligkeit wird zu einem großen Teil durch die Art der Programmierung - und die Ausnutzung der verfügbaren Hilfsmittel - bestimmt. In Perl ("-w") genauso wie in der Shell ("set -u").

Und das ist das problematische. Den die ausgabe selber kann sich unterscheiden. Sie kann sich schon bei unterschiedlichen Distribution unterscheiden, und bei anderen Platformen sowieso.

Die Form der Ausgabe kann ich bei der Mehrzahl der Befehle so steuern, dass ich auf unterschiedlichen Systemen auch die gleiche Ausgabe erhalte.

Sie unterscheidet sich eher nach der Lokalisierung auf Deinem System (was bei Perl genauso zu berücksichtigen ist) und (in weit geringerem Maß) nach der eingesetzten Version des Tools. Aber Kompatibilität ist in der Mehrheit der Fälle leicht durch entsprechende Programmierung zu erreichen - auch ohne umständliche Abfrage der Versionen.

Die immer wiederkehrende Aussage, dass die Unix-/Linux-Tools ihre Ausgaben alle Nase lang umbauen, ist Quatsch und liegt meist daran, dass sich die Leute eben keine Gedanken um Portabilität machen.

Wenn ich z. B. einen "df" auf einem Linux-System absetze und mich dann wundere, dass es auf einem Solaris so ganz anders aussieht, dann habe ich schlicht und einfach die "-k"-Option in der Manualpage übersehen. Und wenn ich mich ärgere, weil in meiner Shell die Überschriften deutsch erscheinen und als root englisch, dann habe ich noch nie was von "LANG=C" gehört:

jan@jack:~> LANG=C df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             20635732   5508324  14079168  29% /
...

Eingebaute Befehle in Perl machen aber egal auf jeden System das gleiche. Sie geben mir das gleiche zurück und machen das gleiche auf den unterschiedlichen Systemen.

Auch bei Perl gibt es Unterschiede zwischen den Versionen. Und auch in Perl gibt es Unterschiede zwischen unterschiedlichen Plattformen (das hatte ich ja schon geschrieben). Auch in Perl musst Du Dir Gedanken über portable Programme machen. Beispiel: UTF-8-Unterstützung (eigene Erfahrung mit Perl::Tk).

Alleine Regexe sind schon ein Punkt. Die Regexe unterscheiden sich in syntax und Funktionalität schon in den unterschiedlichen tools voneinander. Die gleiche Regex kann sogar schlicht bei einem anderen Tool zu einem komplett anderen Match führen.

Siehe oben, das stimmt schlicht und einfach nicht.

Das Programm verbraucht nicht grundlegend 4GiB nur weil es in Perl geschrieben wurde. Wenn du in der Programmierung vorsiehst alles in variablen,arrays,hashes packst dann ist klar das etwas viel ram verbraucht.

Genau das ist der Punkt: Natürlich programmiere ich in Perl anders, weil ich andere Möglichkeiten habe. Wenn ich das nicht tue, geht mir ja der Vorteil flöten, den ich in diesem Fall durch den Einsatz von Perl erlange. Wenn ich die gleichen Methoden wie in einem Shell-Script einsetze, dann bringt mir der Einsatz nichts.

Du argumentierst die ganze Zeit mit den Vorteilen, die Dir Perl bringt - ich habe an dem Beispiel zu zeigen versucht, dass man sich diese Vorteile (z. B. die Möglichkeiten, die Hashes gegenüber den Arrays in der Shell haben) ggf. mit erhöhtem Ressourcenverbrauch erkauft. Wenn Du das "albern" findest ...

Die Möglichkeit, für alles und jedes Module zu finden, ist sicher ein Vorteil von Perl, birgt aber zugleich auch ein paar Nachteile:
- Ich muss bei jedem Non-Standard-Modul erstmal sicherstellen, dass es auch auf jedem Zielsystem vorhanden ist. So ging es mir für ein Perl-Projekt mal mit "POSIX::strptime".
- In jede Modul-Doku muss ich mich neu einlesen; mal ist es eine objektorientierte Schnittstelle, mal nicht, mal gibt es beide, Aufrufsyntax + Parameterübergabe unterscheiden sich, ...

Und zu guter Letzt: Es gibt auch ein paar Sachen, die ich mit Standard-Werkzeugen eleganter hinkriege, als mit Perl: "date +%Y-%m-%d" z.B. sieht in Perl nicht mehr ganz so knackig aus:

my @tm = localtime();
printf "%04d-%02d-%02d\n", $tm[5]+1900,$tm[4]+1,$tm[3];

Jan
EOT

[Sid Burn]

ich gebs auf ...

Hmm, versuchst du mich absichtlich falsch zu verstehen?

Nein, ist es nicht. Die üblichen Tools (u. a. sed, awk, grep) wirst Du immer finden. Perl nicht.

Ja, nur müssen diese Tools nicht identisch sein. Darum geht es. Ein GNU sed ist nicht identis zu einem sed auf einem BSD auf einem Unix oder auf einem Busybox, auf einem Busybox hat sed z.B. kein eingebautes "-i" Schalter.

Wenn du also Shell Skripten lernst musst du immer darauf achten mit welchen Tool auf welchem System du arbeitest, und die benutzung muss nicht identisch sein. Auf jedem System auf dem aber Perl installiert ist, kann ich auch Perl nutzen und die befehle machen nicht je nach System irgendetwas anderes oder es fehlt da etwas.

Du kannst das Shell Skripten an sich zwar nutzen, evtl. musst du dich aber mit jedem System neu herumschlagen und etwas anpassen. Die Portabilität ist also geringer.

z. B. wenn - wie ich ja beschrieben hatte - kein Editor zur Verfügung steht? Ich wollte damit auch nur eine der Möglichkeiten andeuten, in denen Dir auch auf einem halbwegs aktuellen System kein Perl zur Verfügung steht. Wenn Du Dich in Deinen Kenntnissen ausschließlich auf Perl verlässt, dann bist Du in solchen Situationen erschossen. Eine andere Situation: Wie willst Du die - bis heute üblichen - Init-Prozesse auf einem Unix-System verstehen, wenn Du nicht mal die zahlreichen rc-Scripts verstehen kannst?

Mich immer wieder zu wiederholen mag ich irgendwie nicht.
Dann zum dritten mal.
Sich mit dem System auskennen und die Befehle erlernen sollte man sowieso. Ich kenne mich auch ebenfalls mit sed, grep etc. aus. Ein editieren mit sed würde mir also auch nicht schwerfallen. Das ist eine Grundvorraussetzung die man haben sollte. Meine Shell Skripting fähigkeiten reichen auch aus um selber Skripte zu schreiben oder sachen anzupassen. Der Punkt ist aber das wenn man selber neue Programme und Skriopte schreibt die irgendetwas machen sollen das ich da nicht Shell Skripten empfehle sondern lieber etwas höheres. Sei es nun Perl 5, Ruby, Python oder was da sonst jemanden für gut empfindet.

Das jemand sich mit den rc Skripten auskennen sollte, und im fehlerfall sein System reparieren kann etc. sind komplett andere Sachen, ich schrieb ja auch nirgendswo das sich jemand überhaupt nicht mit seinem System auseinander setzen sollte. Sondern nur wenn er "PROGRAMMIERT" eben nicht Shell Skripten mehr nutzt.

Ich hoffe das ich jetzt halbwegs verständlich?

Ja, und bei Nutzung von sed oder awk mache ich genau das Gleiche: Ich nutze die eingebauten Möglichkeiten dieser Tools - alles ohne Forks. Das auslösende Code-Beispiel in sed war genau so eine Variante. Wo lag da der Vorteil von Perl auf der Hand?

Die ursprüngliche Anfrage war wie man eine Aufgabe in Perl löst. Ein aquivalentes programm zu zeigen was es in sed auf der Shell macht ist zwar nett hat mit der eigentlichen aufgabe nichts mehr zu tun.

Wenn er bereits ein Skript hat oder es eben irgendwo anders einbaut etc. pp. dann bringt es ihm auch nichts wenn er weiß wie es in sed machbar ist. Ansonsten sagtest du ja ursprünglich das perl dafür schlecht wäre und es mit sed einfacher geht. Nun wenn man es auf der Shell macht sieht eine Lösung in perl genauso aus. Das sollte nur zeigen das dein weg jetzt nicht bahnbrechend anders ist, es ist nur eben eine andere lösung.

Ansonsten bevorzuge ich Perl gegenüber sed wegen der Regexe. Bei Perl weiß ich wenigstens was geht während die ganzen Tools eben eine leicht andere Regex Engine hat. Ein Beispiel:

sidburn@sid:~$ echo "accz accccccz" | sed 's/ac+z//'
accz accccccz
sidburn@sid:~$ echo "accz accccccz" | perl -pe 's/ac+z//'
 accccccz

Das Verhalten von Perl ist hier das richtige.

Ansonsten waren deine argumente Ressourcenverbrauch. Bei einem einmalkommando das aber sofort wieder alle seine Ressourcen wieder frei gibt, ist dieser Punkt aber eher vernachlässigbar. Und Perl hat auch keine initialen 500MiB Speicherverbrauch so das dies irgendwie relevant wäre. Wenn man für ein aufruf eines einzelnes kommandos nachdenkt ob es nicht evtl. zu viel Speicher verbraucht dann hat man meiner ansicht nach ganz andere Probleme.

Hä? if, while, case usw. sind Shell-Builtins, wo forke ich denn da??? Für den switch gibt es nebenbei gesagt erst in Perl6 eine vernünftige Alternative.

Ja dann denke doch mal ein Schritt weiter. Wenn ich eine while schleife habe oder auch eine if schleife. Dann habe ich doch auch etwas in dieser schleife, oder etwa nicht? Und wie führst du die sachen in dieser schleife aus ohne etwas zu forken? Okay wenn du glück hast und es nur shel built-ins sind, dann forkt es auch nicht. Aber das ist ja nicht immer so.

Daher sobald du irgendeine art von schleifen nutzt wird dein programm auch etwas forken und nicht einmal beim starten alles starten und die programme laufen dann so weiter. Das hast du nur wenn dein programm ein riesieges zusammengepiptes Kommando ist.

Ob das so sinvoll ist, noch anpassbar/wartbar ist oder einfach ist mal eben nachzubauen ist eine andere sache. Schön wäre es wenn man es einfacht so macht wie es am besten passt und sich um das forken nicht kümmern muss.

Lies erstmal die man-Pages, ehe Du sowas schreibst. Alle Tools, die Regex nutzen, verstehen die gleiche Syntax (basic regex: sed, grep; extended regex: awk, sed -r, grep -E). Alle Regex sind POSIX.2 kompatibel. Ein basic regex pattern, das von einem Tool verstanden wird, wird von allen anderen haargenauso interpretiert, bei Extended Regex ist es das Gleiche.

POSIX.2 ist ein Standard keine Implementierung! Auch wenn die ganzen Tools POSIX.2 unterstützen bedeutet es nicht das bei jedem programm die gleiche Regex Engine genutzt wird. Und das ist eben nicht der Fall!

Und selbst wenn sie alle die gleiche Regex engine nutzen. Die Shell bultins sind alle statischen gelinkt. Daher sed, hat die regex engine eingebaut und wird im RAM geladen wenn du sed startest. grep hat die regex engine eingebaut und wird die engine nochmals in den RAM laden, auch wenn es sed schon getan hat. Jedes weitere Tool wird das immer wieder neu laden. Der RAM Verbrauch auf den du ja so wert lägst ist also logsicherweise schon imemr höher. Bei Perl hast du einmal die Regex Engine, sie wird einmal geladen. Volkommen egal wieviele befehle du nun in perl nutzt.

Ansonsten bringt dir POSIX Regex Engine absolut gar nichts! Zu Regexen haben ich das komplette Buch "Reguläre Ausdrücke" gelesen was doch etwas tiefer geht als ein 2 DinA4 Seiten manpage.

Regex Engine gibtes generell zwi Typen. DFA Regex Engines und NFA Regex Engine. Perl ist vom Typ einer NFA Engine. Eine NFA funktioniert ganz anders als eine DFA. Daher die implementierung ist eine andere. Es ist nicht nur so das sie anders funktioniert. Die gleiche Regex matcht bei einem DFA Typ auf etwas anderes als bei einem NFA Typ. Und so wie eine DFA Programmiert ist, ist sie gar nicht erst in der Lage manche Funktionalitäten von einer NFA Regex Engine zu implementieren.

Was z.B. eine DFA überhaupt nicht kann sind einzelne Sachen zu capturen. Daher wenn du mit einer Regex Engine mit Klammern etwas einfängst und nachher wieder darauf zugreifst, soetwas geht mit einem Regex Engine Typ von DFA nicht. Nutzt du soetwas dann muss eine NFA Regex Engine genutzt werden. sed, grep und andere Tools funktionieren so das sie beide Regex Engines implementiert haben. Und je nachdem welches Funktionalitäten du nutzt wird die eine oder andere Engine genutzt.

Was bedeutet das wenn man sed startet beide Engine Typen logischerweise auch beim starten des Programmes geladen werden. Und so macht es noch jedes weitere Tool.

Aha - das ist mir neu. Mit welchen bash-Builtins kannst Du denn Regex verarbeiten?

ich sagte nicht das die Bash Regexe versteht sondern "eine art" von Regexen. Und ja ich meinte da Parameter Expansion. Für viele Sachen kannst du das auch nutzen anstatt auf sed z.B. zurück zu greifen.

Die aussage ist einfach nur. Viele Tools wiederholen sich in Ihrer Funktionalität. Und das kostet alles RAM. Auf den du ja so extrem viel wert legst. Perl hingegen hat die Funktionalitäten von zig Programmen in sich eingebaut, und du nutzt eine gemeinsame basis. Bei Shell Skripten hat jedes Programm seine eigene Basis und verbraucht immer wieder neu RAM. Nutzt du sed, grep, awk. Dann hast du wahrscheinlich 7 verschiedene Regex Engines im Speicher geladen.

Naja, Perl6 ist immer noch nicht released, bisher leben wir mit Perl5. Du willst Unterstützung beim Programmieren in der Shell? Sieh Dir mal im Bash-Manual den Abschnitt über "set" an (z. B. "set -u"). Ach richtig, es lohnt sich ja nicht mehr, sich damit zu befassen.

Schön. Zur Laufzeit findet es variablen die noch nicht gesetzt wurden. "strict" bei Perl macht dies aber zur Compilierzeit.

Und jetzt hast du bei beiden eine ungefähr gleiche Funktionalität, was ist jetzt der Punkt gewesen den du ankreidest? Das man bei Perl kein "strict" nutzen muss? so wie ich kein "set -u" nutzen muss?

Ich habs schon mal geschrieben: Das ist Unsinn. Deine Definition eines Shell-Scripts hat was von einem Tunnelblick.

Aha, das heißt ich muss bei Shell Slkripten gar nicht fremde Programme aufrufen und die rückgabe der Programme parsen? Wie weit kommt man da wenn man es nicht macht?

Die Form der Ausgabe kann ich bei der Mehrzahl der Befehle so steuern, dass ich auf unterschiedlichen Systemen auch die gleiche Ausgabe erhalte.

Mehrzahl != Alle
Und du musst soetwas auch erstmal Wissen. Zu anfang weiß das nicht jeder.

Sie unterscheidet sich eher nach der Lokalisierung auf Deinem System (was bei Perl genauso zu berücksichtigen ist)

Inwiefern? Bei Perl gibt mir ein Befehl nicht etwas anderes zurück nur weil ich eine andere Locale eingestellt habe.

Aber Kompatibilität ist in der Mehrheit der Fälle leicht durch entsprechende Programmierung zu erreichen - auch ohne umständliche Abfrage der Versionen.

Das man es erreichen "kann" habe ich auch nicht angezweifelt. Du musst nur alles mögliche Wissen und beachten das es auch wirklich erstmal geschieht. Das ist aufwendig und das muss ich bei Perl nicht beachten.

Die immer wiederkehrende Aussage, dass die Unix-/Linux-Tools ihre Ausgaben alle Nase lang umbauen, ist Quatsch und liegt meist daran, dass sich die Leute eben keine Gedanken um Portabilität machen.

Ich habe auch nicht behauptet das sie sich alle nase lang ihre ausgabe umbauen. Ich sagte nur das es vorkommt und man sich darauf nicht verlassen kann. Und da die Unix Tools auch nicht Standardisiert sind, findest du schon auf den unterschiedlichen Systemen eben eine andere ausgabe.

Wenn ich z. B. einen "df" auf einem Linux-System absetze und mich dann wundere, dass es auf einem Solaris so ganz anders aussieht, dann habe ich schlicht und einfach die "-k"-Option in der Manualpage übersehen. Und wenn ich mich ärgere, weil in meiner Shell die Überschriften deutsch erscheinen und als root englisch, dann habe ich noch nie was von "LANG=C" gehört:

Und wenn 3) dann...
...
Und wenn 100) dann...
...
Und wenn 1.000.124) dann ...

Hier noch etwas was du beachten kannst bei der ausgabe von df. Wenn Pfade zu lang sind, wird automatisch umgebroch und die ergebnisse auf einer neue zeile angezeigt.

sid:/home/sidburn/iso/diesisteinsehrlangerpfadnurumetwaszusimulieren# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg-root   9.2G  4.2G  4.6G  48% /
tmpfs                 2.0G  8.0K  2.0G   1% /lib/init/rw
udev                   10M  128K  9.9M   2% /dev
tmpfs                 2.0G     0  2.0G   0% /dev/shm
/dev/sda2             4.6G  173M  4.2G   4% /boot
/dev/mapper/vg-home   394G  343G   31G  92% /home
/dev/hda              6.4G  6.4G     0 100% /media/cdrom0
/home/sidburn/iso/diesisteinsehrlangerpfadnurumetwaszusimulieren/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso
                      697M  697M     0 100% /mnt/knoppix

Natürlich kannst du alle ausnahmen lernen. Schöner ist es wenn du keine Ausnahmen hast. Rückgaben von Programmen zu parsen ist nunmal Fehleranfällig.

Und nein, die Ausgabe kommt auch so wenn du die ausgabe des Programmes in einer Datei umleitest.

Auch bei Perl gibt es Unterschiede zwischen den Versionen.

Kannst du ein Beispiel nennen?
Denn eigentlich ist das nicht der Fall. Denn deswegen muss sich Perl 5 immer noch mit sachen herumschlagen die man in einer Perl 5 Programmierungen ncht mehr nutzt, und die eigentlich noch aus der Perl 4 zeit stammen.

Und Perl 5 hat eigentlich ein 10 Jahre Support für Deprecated Features. Sind also Funktionen als Deprecated angesehen, dann saind sie 10 weitere Jahre so verfügbar.

Das ganze war ja auch der Grund Perl 6 zu entwickeln, um die Sprache von Grund auf neu zu bauen was derzeit nicht möglich ist.

Was natürlich so ist, ist wenn du neue Funktionen von neuen Versionen benutzt, das ändert aber nicht die Funktionalität von alten Skripten. Du erhöhst damit letztendlich die minimalversion, ja.

Und auch in Perl gibt es Unterschiede zwischen unterschiedlichen Plattformen (das hatte ich ja schon geschrieben)

Eigentlich nicht, nein (im bezug auf das schreiben).

Auch in Perl musst Du Dir Gedanken über portable Programme machen. Beispiel: UTF-8-Unterstützung (eigene Erfahrung mit Perl::Tk)

Klar, gedanken um Portable Programme musst du dir machen. Von alleine kommt es nicht. Nur es läuft nicht auf die basis hinaus wo ich mich fragen muss. Hmm sortiert ein "sort" in Perl nun auch auf jeder Platform gleich?

Alleine Regexe sind schon ein Punkt. Die Regexe unterscheiden sich in syntax und Funktionalität schon in den unterschiedlichen tools voneinander. Die gleiche Regex kann sogar schlicht bei einem anderen Tool zu einem komplett anderen Match führen.

Siehe oben, das stimmt schlicht und einfach nicht.

Dann kennst du dich schlicht und ergreifend zu wenig mit Regexen aus, wenn du das meinst.

Mein obiges Beispiel mit sed und perl das die gleiche Regex nutzt haben beide ein unterschiedliches verhalten. Mit dem Kommandoswitch "-r" bei sed kannst du es zwar machen das das gleiche dabei heraus kommt wie bei Perl. Aber es zeigt, die gleiche Regex kann unterschiedliches machen je nach Implementation. Bei sed wird danach eine andere Implementation genutzt.

Und die Syntax unterscheidet sich ebenfalls. Perl kennt z.B. "\b" als Word Boundary. Daher es matcht auf eine Position wo wort und nicht wort übergehen. Daher "\w\W" oder "\W\w". Ich meine grep war es, dass "\b" nicht kennt. dafür kennt es aber "\<" und "\>" das die funktion von "\w\W" und "\W\w" annimmt. Die verschiedenen Tools haben definitiv nicht die gleiche Syntax.

Ansonsten wie bereits gesagt, die brauchbaren Regexe mit der Regexe überhaupt sinn machen entsprechen nicht dem POSIX Standard. Der POSIX Standard ist komplett unbrauchbar.

[Sid Burn]

Sorry, musste leider wegen "zu lang" aufgesplitett werden:

Du argumentierst die ganze Zeit mit den Vorteilen, die Dir Perl bringt - ich habe an dem Beispiel zu zeigen versucht, dass man sich diese Vorteile (z. B. die Möglichkeiten, die Hashes gegenüber den Arrays in der Shell haben) ggf. mit erhöhtem Ressourcenverbrauch erkauft. Wenn Du das "albern" findest ...

Dann hast du meine Aussage nicht verstanden wie ich es meinte oder ich war zu undeutlich.

Hashes haben einen erhöhten Speicherverbrauch. ja. Aber nur weil du hashes nutzt braucht dein Programm nicht auf einmal 4GiB RAM und eine Lösung mit Arrays oder in der Shell dümpelt mit 1MiB RAM verbrauch herum. Das ist totaler unsinn.

Wenn du also viel Speicher verbrauchst dann liegt es erstmal an dir. Nicht an der Grundlegenden Benutzung von Perl. Du könntest dein Skript ja auch einmal zeigen wo du so viel RAM verbrauchst mit sample daten? Dann könnte man daran ja mal schauen wo es probleme gibt? Aber ein anderer/neuer Thread wäre dafür besser.

Die Möglichkeit, für alles und jedes Module zu finden, ist sicher ein Vorteil von Perl, birgt aber zugleich auch ein paar Nachteile:
- Ich muss bei jedem Non-Standard-Modul erstmal sicherstellen, dass es auch auf jedem Zielsystem vorhanden ist. So ging es mir für ein Perl-Projekt mal mit "POSIX::strptime".
- In jede Modul-Doku muss ich mich neu einlesen; mal ist es eine objektorientierte Schnittstelle, mal nicht, mal gibt es beide, Aufrufsyntax + Parameterübergabe unterscheiden sich, ...

Das mag stimmen. Aber wenn du die Module nicht hast, musst du unweigerlich "alles" neu und selber Programmieren. Und der aufwand alles selber zu machen ist doch unheimlich höher als sich die Doku durchzulesen oder festzustellen ob ein Modul auf einer Platform geht/oder nicht. Zumal beim neu schreiben immer Punkte gibt die man nicht beachtet hat (zum beispiel das "df" beispiel oben).

Wenn es nicht geht, dann landest du ja sowieso dort was das ohne Modul gemacht hättest. Den du schreibst es selber.

Ansonsten musst du dich bei jedem Shell befehl ebenfalls neu einlesen, genauso wie du dich eben in Moduldokumentation einlesen musst. Ansonsten sind Shell Befehle ja noch nichtmal Standardisiert. Sprich manche Befehle nutzen "-" für Optionen, bei manchen ist es egal. "dd if=dasd of=asd". tar hat ebenso ein anderes Interface etc. Oder kennst du die ganzen befehle praktisch sofort auswendig, ohne dir jemals etwas angeschaut zu haben?

Ansonsten kannst du auch nach alternativen suchen. Für "strptime" kannst du auch http://search.cpan.org/perldoc?Date::Parse nutzen. Date::Parse ist nämlich in Perl geschrieben und Funktioniert überall wo Perl auch läuft. POSIX::strptime ist ein C interface zur POSIX Funktion. Hast du natürlich kein POSIX Kompatibles OS, dann geht das Modul auch nicht.

Und zu guter Letzt: Es gibt auch ein paar Sachen, die ich mit Standard-Werkzeugen eleganter hinkriege, als mit Perl: "date +%Y-%m-%d" z.B. sieht in Perl nicht mehr ganz so knackig aus:

Ja, aber du musst folgende Punkte beachten.
1) Schreibst du ein Shell Skript? Wenn ja würde ich auch auf "date" zurückgreifen.
2) localtime() selber hat erstmal eine ganz andere bedeutung als nur das aktuelle Datum zurück zu geben. localtime() nimmt einen UNIX Timestamp entgegen und splittet es in seine bestandteile auf, mit dennen du dann arbeiten kannst. Wie machst du das mit "date"?
3) Wenn du ein Datum ausgeben möchtest in einem Format dann wäre es auch gut du nutzt eben ein Befehl der dafür auch gedacht war. localtime ist nicht dazu gedacht da er ja nichts Formatiert, sonder ein Datum aufsplittet. Du vergleichst also letztendlich Äpfel mit Birnen. Wenn du ein Datum Formatieren möchtest bietet sich "strftime" aus dem POSIX Modul an, oder "Date::Format" (ich würde eher auf Date::Format zurück greifen).

perl -MPOSIX -wle 'print strftime("%Y-%m-%d", localtime)'

Klar wenn du soetwas auf der Shell nutzen möchtest ist es unsinnig auf perl zuzugreifen. Wenn du aber ein Programm in Perl entwickelst dann ist es nicht mehr unsinnig.
4) Denn wenn du ein Perl Programm schreibst, würde ich keine Shell Befehle aufrufen. Den das setzt vorraus das ein "date" installiert sein muss. Unsinnig wenn es Perl selber auch kann.
5) Selbst wenn du das alles nicht weißt, kann man auch eine Funktion kapseln die das aktuelle Datum in dem Format zurück gibt wie man es haben möchte.

Andere alternative:

perl -MDateTime -wle 'print DateTime->today->ymd("-")'

Nochmal ein Hinweise. Auf der Shell würde ich das nicht nutzen, aber wenn ich davon ausgehe eben ein Perl Programm zu nutzen dann sollte man definitiv nicht auf Shell Programme zurück greifen. Die Beispiele sind nur als "One-Liner" geschrieben zum direkten ausführen.

EDIT:

Für den switch gibt es nebenbei gesagt erst in Perl6 eine vernünftige Alternative.

switch hat man lange Zeit nicht implementiert da es ebenso mit einer if..elsif..elsif..elsif.. konstrukt darstellbar ist. Was aber teilweise besser als ein switch argument ist, ist wenn du eine sogenannte Dispatch Table nutzt http://www.perlmonks.org/?node_id=456530. Ansonsten hat Perl 6 das sogenannte given/when. Das gibt es aber seit Perl 5.10 auch in Perl 5.

http://perldoc.perl.org/perlsyn.html#Switch-statements

[jan61]

Moin,

für mich war zwar EOT, aber Du schreibst ein wenig viel Unsinn.

...Ja, nur müssen diese Tools nicht identisch sein. Darum geht es. Ein GNU sed ist nicht identis zu einem sed auf einem BSD auf einem Unix oder auf einem Busybox, auf einem Busybox hat sed z.B. kein eingebautes "-i" Schalter.

Herrg**t nochmal - natürlich habe ich nicht alle GNU-Optionen auf anderen Systemen. Darum programmiere ich Shell-Scripts portabel, wenn ich sie auch auf anderen Systemen einsetzen will. Das habe ich lang und breit erklärt. Und wenn ich auf ein Uralt-System gehe, dann nehme ich die Korn-Shell (pdksh) statt der Bash.

Auf jedem System, auf dem Perl installiert ist, muss ich mich erstmal umgucken, welche Module bei dieser Distri zum Standard-Installationsumfang gehören und welche ich nachinstallieren muss. Wenn ich Pech habe, ist auf Distri A das Modul in Version 0.93 installiert, welches genau die Features, die ich auf meinem System mit Version 0.94 nutze, nicht vorhanden sind.

Wenn ich dann solche Abhängigkeiten durch manuelles Update auflöse (CPAN), riskiere ich beim nächsten Security-Update eine vermanschte Perl-Installation.

Nochmal (zum x. Mal): Ich versuche nicht, Perl als schlechte Alternative hinzustellen. Aber die "write once - run everywhere"-Methode, die Du hier verbreitest, funktioniert in Perl genauso gut (oder schlecht) wie mit der Shell oder anderen Programmiersprachen.

Wenn du also Shell Skripten lernst musst du immer darauf achten mit welchen Tool auf welchem System du arbeitest, und die benutzung muss nicht identisch sein. Auf jedem System auf dem aber Perl installiert ist, kann ich auch Perl nutzen und die befehle machen nicht je nach System irgendetwas anderes oder es fehlt da etwas.

Blödsinn - siehe oben.

Dann zum dritten mal.
Sich mit dem System auskennen und die Befehle erlernen sollte man sowieso. Ich kenne mich auch ebenfalls mit sed, grep etc. aus. Ein editieren mit sed würde mir also auch nicht schwerfallen. Das ist eine Grundvorraussetzung die man haben sollte.

Ich zitiere aus einer Deiner Mails hier im Thread:

Ich würde jemanden auch nicht mehr empfehlen das Shell Skripten zu lernen, sondern lieber eine der genannten Programmiersprachen.

Was denn nun???

Ich hoffe das ich jetzt halbwegs verständlich?

Nein - s. o.

Die ursprüngliche Anfrage war wie man eine Aufgabe in Perl löst. Ein aquivalentes programm zu zeigen was es in sed auf der Shell macht ist zwar nett hat mit der eigentlichen aufgabe nichts mehr zu tun.

Ich zitiere aus einer meiner Mails:

wenns nicht gleich Perl sein muss...

Sowas heisst im Allgemeinen, dass man eine Alternative vorschlägt. Da ich damals nicht wusste (und wir heute immer noch nicht wissen), in welchem Umfeld die Frage gestellt wurde, erschien es mir passend, einen Blick über den Tellerrand zu wagen. Das hier ist keine Unterrichtsstunde, bei der der Lehrer ein paar Aufgaben an die Tafel malt und genau die Antworten haben will, die er vor 7 Tagen gelehrt hat.

Das sollte nur zeigen das dein weg jetzt nicht bahnbrechend anders ist, es ist nur eben eine andere lösung.

Du wirst wieder mal persönlich. Wo habe ich was von einer bahnbrechenden Lösung geschrieben?

sidburn@sid:~$ echo "accz accccccz" | sed 's/ac+z//'
accz accccccz
sidburn@sid:~$ echo "accz accccccz" | perl -pe 's/ac+z//'
 accccccz

Das Verhalten von Perl ist hier das richtige.

Ein Zitat aus meiner letzten Mail:

Wenn Du in die Falle basic vs. extended regex tappst, dann liegt das eben genau daran, dass Du ja keine Zeit mit dem Erlernen dieser Werkzeuge "verschwenden" willst.

jan@jack:~> echo "accz accccccz" | sed -r 's/ac+z//'
 accccccz

Das Verhalten von Perl ist nicht "richtig", denn Perl nutzt (wie z. B. Java) PCRE (Perl Compatible Regular Expressions), eine Erweiterung des POSIX-Standards für extended regular expressions (die für Perl - wie der Name ja schon sagt - entwickelt wurden), wobei das o. a. Beispiel, wie Du ja siehst, zum Standard-Umfang von Extended Regex gehört.

Ansonsten waren deine argumente Ressourcenverbrauch. Bei einem einmalkommando das aber sofort wieder alle seine Ressourcen wieder frei gibt, ist dieser Punkt aber eher vernachlässigbar. Und Perl hat auch keine initialen 500MiB Speicherverbrauch so das dies irgendwie relevant wäre. Wenn man für ein aufruf eines einzelnes kommandos nachdenkt ob es nicht evtl. zu viel Speicher verbraucht dann hat man meiner ansicht nach ganz andere Probleme.

Nein, denn - auch das habe ich schon geschrieben - man ist in der Regel nicht allein auf dem System. Ein Perl-Script, das für 10 Minuten 90% Rechenlast und 4 GB RAM verbraucht, ist im Tagesbetrieb auf einem Multiuser-System nicht tolerierbar. Ein Perl-Script, das z. B. per cron alle 10 Minuten aufgerufen wird und dann alle anderen Anwendungen blockiert, ist ebenfalls nicht tolerierbar. Ein Dämon, der das System ständig mit 20% Last versorgt, ist oft ebenfalls nicht tolerierbar. Es gibt auch andere Anwendungen und Systemumgebungen als die, die auf Deinem Home-System vorzufinden sind.

Ich muss immer abwägen, in welcher Umgebung meine Programme laufen, was ich als HW-Voraussetzungen brauche und wie ich meine Programme konstruiere. Es mag schon mal angehen, dass ich sage: Diese Programmfunktionalität wird benötigt, also muss entsprechende HW ran. Aber mit der Einstellung "Bei einem einmalkommando das aber sofort wieder alle seine Ressourcen wieder frei gibt, ist dieser Punkt aber eher vernachlässigbar." lachen mich meine Kunden aus!

Ja dann denke doch mal ein Schritt weiter. Wenn ich eine while schleife habe oder auch eine if schleife. Dann habe ich doch auch etwas in dieser schleife, oder etwa nicht? Und wie führst du die sachen in dieser schleife aus ohne etwas zu forken? Okay wenn du glück hast und es nur shel built-ins sind, dann forkt es auch nicht. Aber das ist ja nicht immer so.

Prima, Du hast das hüpfende Komma entdeckt: In dem Fall gucke ich mir Alternativen an. Das kann awk sein (der eine recht gute, C-ähnliche Ablaufsteuerung bietet), das kann sed sein (mit dem man mehr Sachen machen kann, als der gemeine Normaluser vermutet), das kann Perl sein oder wenns schlimm kommt, auch mal Java oder C(++).

Aber ich gehe NIE mit der Einstellung an ein Problem: Jetzt gucke ich mal, wie ich die Frage zu einem Nagel machen kann, damit ich mit meinem Lieblings-Hammer "Perl" arbeiten kann. Andersrum wird ein Schuh draus.

Daher sobald du irgendeine art von schleifen nutzt wird dein programm auch etwas forken und nicht einmal beim starten alles starten und die programme laufen dann so weiter. Das hast du nur wenn dein programm ein riesieges zusammengepiptes Kommando ist.

Nein - Du gehst schon wieder mit Deinem Tunnelblick an die Sache ran. Es gibt Situationen, in denen innerhalb einer Schleife geforkt werden muss, aber nicht jede Schleife beinhaltet den Aufruf externer Kommandos (WENN Du Dich mal intensiver mit der Shell befasst hättest, dann hättest Du - so wie ich - eine Ahnung davon, was alles machbar ist). Und wenn ich sed oder awk nutze, dann vermeide ich eben genau diese Schleifen. Deren Sinn ist es ja gerade, die ganze Datei in einem Rutsch zu bearbeiten. Wenn die nicht mehr passen - s. o.

POSIX.2 ist ein Standard keine Implementierung! Auch wenn die ganzen Tools POSIX.2 unterstützen bedeutet es nicht das bei jedem programm die gleiche Regex Engine genutzt wird. Und das ist eben nicht der Fall!...

Beispiele bitte (und nicht wieder so ein Ding wie oben, wo Du den Unterschied zwischen basic, extended und perl compatible Regex nicht auseinanderhalten konntest).

ich sagte nicht das die Bash Regexe versteht sondern "eine art" von Regexen. Und ja ich meinte da Parameter Expansion. Für viele Sachen kannst du das auch nutzen anstatt auf sed z.B. zurück zu greifen.

Und wieder eine Wiederholung: Das hat nichts, aber auch gar nichts mit Regex zu tun! Das ist der Shell-Mechanismus des "Globbing", der Dir in jedem Kommandoaufruf begegnet, wenn Du mehrere Dateien (auch an Perl!) übergeben willst - und der in Perl nur über die "glob"-Funktion nutzbar ist (Perl kann nämlich nicht z. B. in einem opendir() mit Platzhaltern arbeiten). Wenn Du diese Syntax anstelle Regex nutzt (da war mal vor ein paar Ausgaben ein ct-Artikel, der solchen Unsinn vorgeschlagen hat), dann kriegst Du wirklich Probleme!

Die aussage ist einfach nur. Viele Tools wiederholen sich in Ihrer Funktionalität.

Urgs - das ist ja nun kompletter Unsinn. Jedes Tool hat andere Funktion und einen anderen Einsatzbereich. Eben hast Du Dich noch beschwert, dass angeblich alle Tools unterschiedlich arbeiten, jetzt beschwerst Du Dich, dass alle die gleiche Regex-Funktionalität bieten.

Ich benutze ja nicht 5 Tools auf einmal - ich benutze das am besten geeignete Tool. Warum soll ich z. B. einen sed und einen awk gleichzeitig auf eine Datei loslassen? Das kann ich doch im awk allein erledigen. Warum soll ich mit grep Zeilen aus einer Datei flöhen und dann per sed ändern? Das kann sed doch ganz allein.

Schön. Zur Laufzeit findet es variablen die noch nicht gesetzt wurden. "strict" bei Perl macht dies aber zur Compilierzeit.

Wow - Perl kompiliert? Die Fehler sehe ich im gleichen Augenblick, in dem ich sie auch in der Shell sehe: Wenn ich das Script starte. Was für einen Unterschied macht es, wie die Interpreter intern arbeiten?

Und jetzt hast du bei beiden eine ungefähr gleiche Funktionalität, was ist jetzt der Punkt gewesen den du ankreidest? Das man bei Perl kein "strict" nutzen muss? so wie ich kein "set -u" nutzen muss?

Zum x+1. Mal: Ich will nicht Perl irgendwas ankreiden, sondern (in dem von Dir genannten Beispiel) klarmachen, dass die Shell bei weitem mehr Möglichkeiten hat, als Du kennst und dass die Shell viele der Mechanismen kennt, die Du nur in Perl siehst.

Aha, das heißt ich muss bei Shell Slkripten gar nicht fremde Programme aufrufen und die rückgabe der Programme parsen? Wie weit kommt man da wenn man es nicht macht?

Ganz offensichtlich viel weiter, als Du es Dir vorstellen kannst.

Mehrzahl != Alle
Und du musst soetwas auch erstmal Wissen. Zu anfang weiß das nicht jeder.

Das weiß auch ein Perl-Programmierer nicht, bevor er die Modul-Dokus gelesen hat.

Inwiefern? Bei Perl gibt mir ein Befehl nicht etwas anderes zurück nur weil ich eine andere Locale eingestellt habe.

jan@jack:~> perl -MPOSIX -wle 'print strftime("%b", localtime)'
Mai
jan@jack:~> LANG=C perl -MPOSIX -wle 'print strftime("%b", localtime)'
May

Ich sagte nur das es vorkommt und man sich darauf nicht verlassen kann. Und da die Unix Tools auch nicht Standardisiert sind, findest du schon auf den unterschiedlichen Systemen eben eine andere ausgabe.

Und wieder zeigt Deine Antwort, dass Du Dich eben nicht auskennst - die Behauptung ist einfach lächerlich. Es gibt seit mehr als 20 Jahren POSIX und SysV.

Hier noch etwas was du beachten kannst bei der ausgabe von df. Wenn Pfade zu lang sind, wird automatisch umgebroch und die ergebnisse auf einer neue zeile angezeigt.

Ja und? Dann berücksichtige ich das, ist nicht schwer (da gibts IIRC einen Thread genau zu dem Thema hier).

Ich habe mal auf CPAN gestöbert - 124 Ergebnisse zu "file system", 200 zu "df" (von denen die ersten nichts mit dem Kommando zu tun haben) - ehe ich da das passende Modul gefunden, installiert, die Doku gelesen und ein Perl-Script geschrieben habe, ist mein Shell-Script schon in Rente gegangen - das hätte ich in C schneller hingekriegt. Ich finde ja nicht mal über "apropos" oder die Suche in Yast ein Ergebnis.

Kannst du ein Beispiel nennen?

Hatte ich bereits: Perl::Tk.

Eigentlich nicht, nein (im bezug auf das schreiben).

Liest Du eigentlich meine Posts, bevor Du antwortest? Und wieder ein Zitat aus diesem Thread (Post von mir):

(siehe z. B. "perldoc -f unlink" oder "perldoc -f mkdir").

...Hmm sortiert ein "sort" in Perl nun auch auf jeder Platform gleich?

Nein, tut er nicht. Aus "perldoc -f sort":

When "use locale" is in effect, "sort LIST" sorts LIST according to the current collation locale. See perllocale.

Dann kennst du dich schlicht und ergreifend zu wenig mit Regexen aus, wenn du das meinst.

Mein obiges Beispiel mit sed und perl das die gleiche Regex nutzt haben beide ein unterschiedliches verhalten. Mit dem Kommandoswitch "-r" bei sed kannst du es zwar machen das das gleiche dabei heraus kommt wie bei Perl. Aber es zeigt, die gleiche Regex kann unterschiedliches machen je nach Implementation. Bei sed wird danach eine andere Implementation genutzt.

Den ersten Satz interpretiere ich einfach mal als eine weitere verbale Entgleisung. Der Rest zeigt mir deutlich, dass Du ein wenig Nachholbedarf in Sachen "was ist ein Standard?" hast. Standards entwickeln sich. So wie sich ein Standard wie HTML bis hin zu Version 4 (strict/transitional) und XHTML entwickelt hat, so haben sich Regex entwickelt. Die Schalter "-r" für sed und "-E" für grep schalten einfach nur den Level der Unterstützung der Standards für "basic" oder "extended" Regex um - genauso wie es z. B. Browser beim Empfang von Seiten mit entsprechenden Headern tun. Perl versteht nur eine Art, nämlich PCRE (um proprietäre Elemente erweiterte extended regex) - was u. a. bedeutet, dass Perl keine basic regex versteht, sofern sie sich in der Syntax von PCRE unterscheiden.

Standards als "unbrauchbar" zu bezeichnen, ist genau die Art, wenn der man sein eigenes proprietäres Geraffel unter die Leute bringen will. Das macht M$ auch jeden Tag.

Disclaimer: Ich finde nicht, dass PCRE schädlich sind - nur die Art und Weise, wie Du diese als einzige Wahrheit unter die Leute bringen willst. So nach dem Motto: Alle Unix-Tools sind Sch*** weil sie nicht wie Perl reagieren. Auch Perl ist nur eine unter vielen Programmiersprachen.

Jan

P.S.: Ich schlage vor, wir beenden diese Diskussion. Wenn Du willst, gern per PM mehr, aber ich habe mich hier schon zu oft wiederholt.