Mailinglist Archive: opensuse-de (5887 mails)
| < Previous | Next > |
Re: Welche Shell fü r welchen Zweck?
- From: Bernhard Walle <Bernhard.Walle@xxxxxx>
- Date: Sun, 9 Jun 2002 15:25:17 +0200
- Message-id: <20020609132517.GC1232@xxxxxxxxxxxxxxx>
On Sun, 09 Jun 2002 at 10:45 (+0200), Bernd Brodesser wrote:
> * Thorsten Haude schrieb am 08.Jun.2002:
> > * Bernd Brodesser <B.Brodesser@xxxxxxxxxxx> [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
> * Thorsten Haude schrieb am 08.Jun.2002:
> > * Bernd Brodesser <B.Brodesser@xxxxxxxxxxx> [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
| < Previous | Next > |