On Sun, 09 Jun 2002 at 10:45 (+0200), Bernd Brodesser wrote:
* Thorsten Haude schrieb am 08.Jun.2002:
* Bernd Brodesser
[02-06-08 17:55]: * Thorsten Haude schrieb am 08.Jun.2002:
In C würde ich viele Dinge in dem Bereich nicht machen, weil es Sicherheitslücken zu einfach macht. Ich habe diese Ansicht auch schon
Sicherheitslücken? Mit C?
Stichwort Bufferoverruns. Ist aber nur das populärste Beispiel, mit C muß man allgemein präziser arbeiten, dadurch dauert es entweder länger oder ist anfälliger.
Weil man präziser arbeiten muß wird es anfälliger?
Nein. Aber in C kann man Fehler machen, die man nicht oder spät merkt (etwa, wenn man über den vorhandenen Speicher hinausschreibt) aber eben Sicherheitslücken sind. Sicherheitslücken dieser Art kann man in Perl nicht produzieren, weil man sich um das Thema Speicher keine Gedanken machen muss.
Das Gegenteil ist der Fall. Es ist der große Nachteil von perl, daß man da recht schlampig mit arbeiten kann, und auch Code so schreiben kann, daß ihm niemand mehr nachvollziehen kann.
Oder ein Vorteil. Ich kann so programmieren, wie ich es möchte und für diesen speziellen Fall für richtig halte. Ich kann mich dazu zwingen, Variablen zu deklarieren (use strict;), kann es aber auch bleiben lassen. Ich kann den Taint-Modus einschalten (-T), insb. bei CGI-Skripten sinnvoll, kann es aber bleiben lassen. Perl lässt mir als Programmierer die Wahl, wie ich gerne arbeiten möchte. Und das ist in vielen Fällen ein klarer Vorteil. Wir reden hier nicht von Programmen, die zehntausende an Zeilen Code enthält, an denen mehrere Entwickler arbeiten etc. Es ging um Dinge, die man klassisch mit Shellskripten erledigt. Und: Mit der Shell kann ich das _nicht_. Ich kann mich nicht zwingen, Variablen zu deklarieren, selbst wenn ich das möchte.
Ich rede nicht mal von böswillig unübersichtlichen Code. Es reichen verschiedene Stile von verschiedene Programmierer.
TMTOWTDI. ;-) ¹
begründet, darum wäre es nett, wenn Du mal ein Beispiel im Bereich Shellskripte nennst, bei dem C überlegen wäre. Überall dort wo es zeitkritisch wird. Also nicht im Bereich Shellskripte.
Nun, man kann jetzt sagen, immer da wo es Zeitkritisch wird, ist nicht im Bereich der Shellskripte.
Schön langsam kann ich das Wort zeitkritisch nicht mehr hören. Bei größeren Sachen (die _nicht_ zeitkritisch sind) finde ich jedenfalls Perl die deutlich bessere Wahl als Shellskripte. Perl ist schonmal wesentlich portabler. Während ich auf jedem unixoiden Betriebssystem eine andere Shell habe, ist Perl _eine_einheitliche_ Programmiersprache. Wenn ich Perl installiere, dann habe ich Perl. Natürlich kann es Probleme mit unterschiedlichen Versionen geben, aber die kann man relativ leicht abfragen. Und mit was kleinerem wie Perl 5.005 muss man nicht wirklich rechnen. Selbst wenn ich bei der Portabliität über Unix hinausgehen will, kann ich das mit Perl²: Perl gibt's für Windows, OS/2 oder sogar MS-DOS (mit Einschränkungen). Und das, ohne gleich ein halbes Unix installieren zu müssen (Cygwin). Mit Perl brauche ich nicht ständig externe Programme aufrufen, sei es sed, awk, cut, head, tail, ..., nur um einfachste Operationen mit Text zu machen. Und ich brauche micht nicht mit all diesen Programmen zu beschäftigen, die alle ihre eigene Syntax haben, die alle unterschiedlich funktionieren. Und es wird nicht jedesmal ein neuer Prozess gestartet, insofern ist Perl deutlich schneller als die Shell. Für Perl gibt es hunderte von Modulen im CPAN. Wie erweiterst Du die Bash? Mit externen Programmen ... Und: Perl ist IMHO deutlich besser dokumentiert als die Shell. Ja, es gibt man bash, aber erstens wird da nirgendwo auf Unterschiede zwischen einzelnen Shells eingegangen, zweitens ist eine große Manpage recht unübersichtlich, drittens kann ich Perl-Dokumentation in verschiedenen Formaten haben und viertens ist perldoc -f oder perldoc -q _sehr_ nützlich. Und nur mal am Rande: Perl eignet sich hevorragend zum Programmieren von CGI-Skripten, auch wenn man bei größeren Sachen wohl PHP, JSP, ASP oder Servlets bevorzugut. Hier ist C in vielen Fällen gar nicht möglich, weil man kompilieren muss und vielfach gar keinen Shell/SSH-Zugang zu dem System hat, wo das Skript letztendlich liegt. Wenn man also nicht zufällig zu Hause das gleiche System hat, unter dem auch der Server läuft, geht's gar nicht. Man hat also deutlich mehr davon, Perl zu lernen als sich mit allen möglichen Shellskript- Helferchen auseinanderzusetzen. Nein, Perl als einen sed-&-awk-Ersatz hinzustellen grenzt an eine Beleidigung. Gruß, Bernhard ¹ Wer "Programmieren in Perl" gelesen hat, weiß, was es bedeutet. Für die anderen in ROT13: Gurer'f Zber Guna Bar Jnl Gb Qb Vg ² Was nicht heißen soll, dass jedes Perlskript unter Win32 läuft. Ich _kann_ so programmieren, ich _muss_ es aber nicht. -- Machine Always Crashes, If Not, The Operating System Hangs (MACINTOSH) -- Topic on #Linux