* Adalbert Michelic schrieb am 30.Mai.2002:

Was spricht dagegen, /bin/false zu verwenden? Oder /bin/true? /bin/true ist das gleiche wie /bin/false, nur unter anderem Namen - nämlich ein Programm, das nichts macht.

Falsch. /bin/true gibt einen Exitcode 0 zurück und /bin/false den Exitcode 1. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4

Hallo, On Mon, 03 Jun 2002 at 09:25 (+0200), Ralf Corsepius wrote:

Perl ist für gewisse Anwendungsfälle zweckmässig, für andere Fälle wiederum nicht.

ACK. Wenn es darum geht, dass viele Dateioparationen getätigt werden müssen, würde ich immer noch ein Shellskript schreiben. Geht es hingegen um die Verarbeitung von Textdateien, wo man sed, awk & Co. bräuchte, dann ist IMHO Perl erste Wahl. Gruß, Bernhard -- If you really want pure ASCII, save it as text... or browse it with your favorite browser... -- Alexandre Maret

* Thorsten Haude schrieb am 03.Jun.2002:

Mir geht's vor allem um Probleme, die man nicht mal eben mit ein paar Zeilen zusammenschreibt. Auch wenn viele Dateioperationen gebraucht werden, kann Perl schnell lohnen, wenn die Logik kompliziert wird, und open(HANDLE, "...|") ist eigentlich recht elegant.

Aber dann kanst Du gleich C nehmen. Auch nicht komplizierter, aber schneller in der Ausführung. Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: http://localhost/doc/sdb/de/html/index.html | mit Apache: http://localhost/doc/sdb/de/html/key_form.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2

* Thorsten Haude schrieb am 04.Jun.2002:

* Bernd Brodesser [02-06-04 11:01]:

...

* Thorsten Haude schrieb am 03.Jun.2002:

...

Aber dann kanst Du gleich C nehmen. Auch nicht komplizierter, aber schneller in der Ausführung. Ich gehe davon aus, daß Du schonmal Stringoperationen in C gemacht hast, darum verstehe ich Deine Aussage nicht.

Ich habe schonmal Stringoperationen in C gemacht und weiß nicht, wo das Problem sein soll? Bernd

Hallo, On Wed, 05 Jun 2002, Christoph Maurer wrote:

Trotzdem hast Du natürlich recht, das C schneller [als perl] in der Ausführung und deshalb u.U. vorzuziehen ist, aber im Normalfall würde ich stringbearbeitende Aufgaben mit Perl lösen (und in der Zeit, die ich dadurch gegenüber C einspare, hole ich den Rechenzeitnachteil für viele, viele Aufrufe eines Programms raus).

Hast du mal Benchmarks gemacht? i.d.R ist perl nur beim ersten Starten signifikant langsamer, und dann gibt's noch den perlcc, der die zum starten benoetigte reduzieren kann. Der eigentliche Code laeuft dann so schnell wie in C, natuerlich[1] aber etwas langsamer als was selbst- geschriebenes, da eben perl einen gewissen Code[2]-overhead bedingt. -dnh [1] zumindest bei Sachen, die sich relativ einfach in C schreiben lassen, wird's komplex, dann ist u.U. der generische und optimierte Code von perl schneller... [2] nicht Laufzeit- -- "Don't put off 'till tomorrow, responsibilities. They'll just come back to haunt you. (Ignore them totally)" -- TISM

* Thorsten Haude schrieb am 05.Jun.2002:

* Bernd Brodesser [02-06-05 00:22]:

...

Ich habe schonmal Stringoperationen in C gemacht und weiß nicht, wo das Problem sein soll?

Erklär doch mal den Unterschied zwischen strlcpy() und strncpy(), dann

Was ist strlcpy? Meinst Du strcpy? Der Unterschied ist ganz einfach: Bei strncpy muß Du als drittes Argument noch die maximale Länge mitgeben. Bei strcpy wird gnadenlos kopiert, bis eine NUL erreicht wird. strncpy macht das gleiche, bricht aber bei n Zeichen ab, wenn bis dahin immer noch keine NUL erreicht wurde. strcpy würde bis in aller Ewigkeit weiterkopieren. Wenn Du eine Zeichenkette unbekanter Länge hast, und diese Zeichenkette auf einer anderen kopieren möchtest, so steht Dir nur ein begrenzter Speicherraum zur Verfügung. Daher muß man da strncpy verwenden. Wenn Du dies aber einmal gemacht hast, dann kann der string ja nicht mehr größer werden. Dann kanst Du im Folgenden strcpy verwenden. Nun gut, kopieren und dann noch mal kopieren ist vielleicht nicht so überzeugend, aber strncpy steht ja auch nur stellvertretend für viele strn... Routinen.

beschreib mal, wie das Problem in Perl gehandhabt wird. Dann wird mir vielleicht klar, warum Stringoperationen in C auch nicht komplizierter sind.

Ich habe nicht gesagt, daß es in C nicht komplizierter ist, aber es ist auch nicht so schlimm. C ist nun einfach Maschienennäher und daher auch schneller. Ich weiß es nicht, aber es besteht eine gute Chance, daß etwa perl selber in C geschrieben ist, oder die bash, oder... mutt schriebe ich auch nicht in perl. Bernd -- Umsteiger von Microsoft Windows xx? Hast Du schon file://usr/doc/howto/de/DE-DOS-nach-Linux-HOWTO.txt gelesen? Auch file://usr/doc/Books/Linuxhandbuch.dvi ist zu empfehlen. |Zufallssignatur 1

Moin, * Bernd Brodesser [02-06-05 12:54]:

* Thorsten Haude schrieb am 05.Jun.2002:

...

* Bernd Brodesser [02-06-05 00:22]:

...

Ich habe schonmal Stringoperationen in C gemacht und weiß nicht, wo das Problem sein soll? Erklär doch mal den Unterschied zwischen strlcpy() und strncpy(), dann Was ist strlcpy? Meinst Du strcpy? Nö, das wäre langweilig. http://www.google.com/search?q=strlcpy

Nun gut, kopieren und dann noch mal kopieren ist vielleicht nicht so überzeugend, aber strncpy steht ja auch nur stellvertretend für viele strn... Routinen. ...die alle in Perl vollständig überflüssig sind.

...

beschreib mal, wie das Problem in Perl gehandhabt wird. Dann wird mir vielleicht klar, warum Stringoperationen in C auch nicht komplizierter sind. Ich habe nicht gesagt, daß es in C nicht komplizierter ist Doch, in 20020604090137.GA2880@b.brodesser.dialin.t-online.de: "Aber dann kanst Du gleich C nehmen. Auch nicht komplizierter (...)"

C ist nun einfach Maschienennäher und daher auch schneller. Ich weiß es nicht, aber es besteht eine gute Chance, daß etwa perl selber in C geschrieben ist, oder die bash, oder... mutt schriebe ich auch nicht in perl. Die sind alle drei in C geschrieben. Ich habe nicht das geringste gegen C, ich programmiere momentan mehr in C als in allen anderen Sprachen zusammen. Perl habe ich aber als Ersatz für Shellskripte ins Gespräch gebracht, das ist schlicht kein Platz für C.

Thorsten -- Guns don't protect freedom, people protect freedom.

Moin, * Bernhard Walle [02-06-05 21:49]:

On Wed, 05 Jun 2002 at 21:38 (+0200), Thorsten Haude wrote:

...

* Bernd Brodesser [02-06-05 12:54]:

...

* Thorsten Haude schrieb am 05.Jun.2002:

...

* Bernd Brodesser [02-06-05 00:22]:

...

Ich habe schonmal Stringoperationen in C gemacht und weiß nicht, wo das Problem sein soll? Erklär doch mal den Unterschied zwischen strlcpy() und strncpy(), dann Was ist strlcpy? Meinst Du strcpy? Nö, das wäre langweilig. http://www.google.com/search?q=strlcpy Scheint es aber unter Linux nicht zu geben. Ja und? Du sollst den Unterschied erklären, kein Programm schreiben.

Weder "man strlcpy", noch eine Suche in der Info-Datei zur libc ("pinfo libc" und dann Volltextsuche) noch eine Suche in /usr/include/string.h führen bei mir zum Erfolg. Argl. Schonmal Google versucht? Die URL findest Du in einer der folgenden Mails: 20020605193800.GA930@eumel.yoo.net 20020605194933.GA18276@mail1.bwalle.de

Thorsten -- Golly, I'd hate to have a kid like me! - Calvin

Moin,

* Bernhard Walle  [02-06-05 23:50]:
>On Wed, 05 Jun 2002 at 22:06 (+0200), Thorsten Haude wrote:
>> * Bernhard Walle  [02-06-05 21:49]:
>> >Weder "man strlcpy", noch eine Suche in der Info-Datei zur libc
>> >("pinfo libc" und dann Volltextsuche) noch eine Suche in
>> >/usr/include/string.h führen bei mir zum Erfolg.
>> Argl. Schonmal Google versucht? Die URL findest Du in einer der
>> folgenden Mails:
>>     20020605193800.GA930@eumel.yoo.net
>>     20020605194933.GA18276@mail1.bwalle.de
>Warum so umständlich, die URL steht doch noch oben im Quoting?
Ach tatsächlich?

>Außerdem: Ich weiß, wie man Google bedient und ich habe auch den Link
>schon aufgerufen, bevor ich obige Mail verfasst habe. Allerdings: Was
>interessieren mich Funktionen, die es (unter Linux) gar nicht gibt und
>die offensichtlich auch in keinen Standards (weder POSIX noch ANSI/ISO
>C** noch sonstwas) enthalten sind?
Der Unterschied soll (!) Dich nur darüber nachdenken lassen, warum
evtl. manche Leute behaupten, daß Stringoperationen in Perl einfacher
zu machen sind als in C. Die Tatsache, daß strlcpy() nicht auf allen
Plattformen zur Verfügung steht, ist ein weiteres Argument dafür.

>Der Unterschied macht sich v. a. dann bemerkbar, wenn der src-String
>länger ist als n. Während mir strlcpy() garantiert, dass der neue String
>mit \0 abgeschlossen wird, ist das bei strncpy() nicht der Fall. Hier
>wird einfach nach n Bytes mit dem Kopieren aufgehört und der neue
>String ist eben nicht \0-terminiert.
Diese Aufgabe wird in Perl für Strings beliebiger Länge so gelöst:
    $a = $b;

>Auf der anderen Seite muss bei strlcpy() der src-String \0-terminiert
>sein; bei strncpy nicht; d. h. während strncpy() einfach bei n
>aufhört zu lesen schaut sich strlcpy() den ganzen String an, was
>AFAIK zu Speicherzugriffsfehlern führen kann. 
Woran erkennst Du das? Ich kann das nicht erkennen:
- - - Schnipp - - -
The strlcpy() function copies up to size - 1 characters from the
NUL-terminated string src to dst, NUL-terminating the result.
- - - Schnapp - - -

Thorsten
-- 
As long as people will accept crap, it will
be financially profitable to dispense it.
	- Dick Cavett

Moin,

* Bernhard Walle  [02-06-06 10:00]:
>On Thu, 06 Jun 2002 at 00:25 (+0200), Thorsten Haude wrote:
>> * Bernhard Walle  [02-06-05 23:50]:
>> Der Unterschied soll (!) Dich nur darüber nachdenken lassen, warum
>> evtl. manche Leute behaupten, daß Stringoperationen in Perl einfacher
>> zu machen sind als in C. 
>Habe ich das behauptet? Bernd hat das behauptet, nicht ich.
>Bernd => Bernd Brodesser
>Ich => Bernhard Walle
Oops, da habe ich die Bs verwechselt, sorry.

>> >Auf der anderen Seite muss bei strlcpy() der src-String \0-terminiert
>> >sein; bei strncpy nicht; d. h. während strncpy() einfach bei n
>> >aufhört zu lesen schaut sich strlcpy() den ganzen String an, was
>> >AFAIK zu Speicherzugriffsfehlern führen kann. 
>> Woran erkennst Du das? Ich kann das nicht erkennen:
>> - - - Schnipp - - -
>> The strlcpy() function copies up to size - 1 characters from the
>> NUL-terminated string src to dst, NUL-terminating the result.
>> - - - Schnapp - - -
>- - - Schnipp - - -
>Also note that strlcpy() and strlcat() only operate on true ``C''
>strings.  This means that for strlcpy() src must be NUL-terminated and
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>for strlcat() both src and dst must be NUL-terminated.
>- - - Schnapp - - -
>
>- - - Schnipp - - -
>[...]Unlike those functions, strlcpy() and strlcat() take the full
>size of the buffer (not just the length)
>- - - Schnapp - - -
Schon wieder oops, habe ich glatt überlesen. Allerdings ist auch im
bösen Fall (zu langer src) ein sauberer String gewährleistet, das
macht den Unterschied aus.

Thorsten
-- 
Just because you do not take an interest in politics
doesn't mean politics won't take an interest in you.
    - Pericles

Moin, * Bernd Brodesser [02-06-06 10:27]:

* Thorsten Haude schrieb am 06.Jun.2002:

...

* Bernhard Walle [02-06-05 23:50]:

...

Außerdem: Ich weiß, wie man Google bedient und ich habe auch den Link schon aufgerufen, bevor ich obige Mail verfasst habe. Allerdings: Was interessieren mich Funktionen, die es (unter Linux) gar nicht gibt und die offensichtlich auch in keinen Standards (weder POSIX noch ANSI/ISO C** noch sonstwas) enthalten sind? Der Unterschied soll (!) Dich nur darüber nachdenken lassen, warum evtl. manche Leute behaupten, daß Stringoperationen in Perl einfacher zu machen sind als in C. Die Tatsache, daß strlcpy() nicht auf allen Plattformen zur Verfügung steht, ist ein weiteres Argument dafür. Wahnsinn.

strncpy (newstring,oldstring,n); newstring [n-1] = '\0'; Du hast vergessen, Speicher zu allozieren.

Jetzt eine Funktion; wie sieht das in C aus: - - - Schnipp - - - sub weekDay { return (localtime)[6]; } - - - Schnapp - - -

...

Diese Aufgabe wird in Perl für Strings beliebiger Länge so gelöst: $a = $b; Schön. Und warum wird es in C wohl nicht so gemacht? Weil C älter ist und andere Ziele hat.

Thorsten -- Guns don't protect freedom, people protect freedom.

Moin, * Bernhard Walle [02-06-06 20:08]:

On Thu, 06 Jun 2002 at 19:37 (+0200), Thorsten Haude wrote:

...

* Bernd Brodesser [02-06-06 10:27]:

...

strncpy (newstring,oldstring,n); newstring [n-1] = '\0'; Du hast vergessen, Speicher zu allozieren. Was heißt "allozieren". Wahrscheinlich meinst Du das, was ich als allokieren (oder schlicht zuteilen) bezeichnen würde. Daß man sich darum selbst kümmern muß, ist eines der großen Nachteile von C. ('Allozieren' ist eindeutig, darum benutze ich nicht 'zuteilen'.)

...

Jetzt eine Funktion; wie sieht das in C aus: - - - Schnipp - - - sub weekDay { return (localtime)[6]; } - - - Schnapp - - -

Wahrscheinlich irgendwie so ähnlich:

- - - schnipp - - - #include

int weekDay (void) { time_t my_time; struct tm *my_tm;

time(&my_time); my_tm = localtime(&my_time);

return my_tm->tm_wday; } - - - schnapp - - - So wird das nicht gehen. Selbst, wenn my_tm statisch wäre, hättest Du ein Problem, wenn die Funktion mehrfach aufgerufen wird und sich der erste Caller darauf verläßt, daß der Wert gleich bleibt.

Wird das jetzt ein Quiz "PerlToC"? Sieht so aus.

...

...

...

Diese Aufgabe wird in Perl für Strings beliebiger Länge so gelöst: $a = $b; Schön. Und warum wird es in C wohl nicht so gemacht? Weil C älter ist und andere Ziele hat. Eben. Ich finde die Diskussion hier eigentlich ziemlich überflüssig. Gerade Perl und C sind doch zwei Sprachen, die sich mehr ergänzen als konkurrieren. Auf jeden Fall. Es geht nur um die Frage, ob C ähnlich gut wie Perl als Ersatz für Shellskripte eignet.

Thorsten -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. - Grundgesetz, Artikel 10, Abs. 1

Moin, * Bernhard Walle [02-06-06 21:29]:

On Thu, 06 Jun 2002 at 20:34 (+0200), Thorsten Haude wrote:

...

* Bernhard Walle [02-06-06 20:08]:

...

Was heißt "allozieren". Wahrscheinlich meinst Du das, was ich als allokieren (oder schlicht zuteilen) bezeichnen würde. ('Allozieren' ist eindeutig, darum benutze ich nicht 'zuteilen'.) Und was ist der Unterschied zwischen "allozieren" und "allokieren". Da mache ich keine Unterscheide.

...

...

...

Jetzt eine Funktion; wie sieht das in C aus: - - - Schnipp - - - sub weekDay { return (localtime)[6]; } - - - Schnapp - - -

Wahrscheinlich irgendwie so ähnlich: - - - schnipp - - - #include

int weekDay (void) { time_t my_time; struct tm *my_tm;

time(&my_time); my_tm = localtime(&my_time);

return my_tm->tm_wday; } - - - schnapp - - - So wird das nicht gehen. Wieso? Weiß ich auch nicht. Das war nicht nur ein schlechtes Beispiel, sondern auch noch falsch von mir gedacht.

Nehmen wir einen String: - - - Schnipp - - - sub parseFilename { $filename = shift; $filename =~ /(.*)\/([^\/]+)/; return $1, $2 } - - - Schnapp - - -

Könntest Du bitte _etwas_ deutlicher werden. Wir können gerne eine normale Diskussion miteinander führen. Aber auf dem Niveau, dass Du der Oberlehrer bist und ich der dumme Schüler, wird mir das schön langsam zu blöd. Sorry, das war so nicht geplant.

Thorsten -- It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein

* Bernhard Walle schrieb am 06.Jun.2002:

C ist schnell, dafür muss man sich um vieles selber kümmern. Perl ist etwas langsamer, dafür muss man sich um so Dinge wie Speicher absolut keine Gedanken machen. Solange Speicher zur Verfügung steht, sorgt Perl dafür, dass er richtig genutzt wird. :-)

Ist aber nicht über anwendbar. Etwa perl selber. Das muß auch in irgendwas geschrieben werden. Da ist C doch gut für geeignet. Es hat schon seinen Grund, warum komplexere Sachen in C geschrieben werden. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0

* Bernhard Walle schrieb am 07.Jun.2002:

On Fri, 07 Jun 2002 at 12:56 (+0200), Bernd Brodesser wrote:

...

* Bernhard Walle schrieb am 06.Jun.2002:

...

C ist schnell, dafür muss man sich um vieles selber kümmern. Perl ist etwas langsamer, dafür muss man sich um so Dinge wie Speicher absolut keine Gedanken machen. Solange Speicher zur Verfügung steht, sorgt Perl dafür, dass er richtig genutzt wird. :-)

Ist aber nicht über anwendbar.

Diesen Satz verstehe ich nicht. Vielleicht wolltest Du sagen "Ist aber nicht immer anwendbar." oder "Ist aber nicht überall anwendbar.".

Ja.

...

Etwa perl selber. Das muß auch in irgendwas geschrieben werden. Da ist C doch gut für geeignet. Es hat schon seinen Grund, warum komplexere Sachen in C geschrieben werden.

Es hat doch kein Mensch behauptet, dass sich Perl eigenet, alles zu schreiben. Es ging doch _nur_ um _Skripte_ zur _Systemadministration_. Warum siehst Du nicht ein, dass _auch_Perl_ seine Berechtigung hat, insb. für solche Sachen, und C nicht für _alles_ die optimale Lösung ist?

Es ging um kompliziertere Skripte. Und da sage ich, da ist meist C die bessere Wahl. Für einfache Skripte eignet sich mehr die bash. Ich sehe nicht, daß perl die bash verdrängt. Auch perl hat seinen Platz, nämlich überall da wo man früher mit sed oder awk gearbeitet hat. Bernd -- Bei Fragen an die Liste erst mal nachschauen, ob es diese Frage nicht schon einmal gegeben hat. Ein Archiv der Liste findest Du auf: http://lists.suse.com/archives/suse-linux |Zufallssignatur 7

Am Sam, 2002-06-08 um 00.06 schrieb Thorsten Haude:

Moin,

* Bernd Brodesser [02-06-07 21:20]:

...

Es ging um kompliziertere Skripte. Und da sage ich, da ist meist C die bessere Wahl. Für einfache Skripte eignet sich mehr die bash. Ich sehe nicht, daß perl die bash verdrängt. Auch perl hat seinen Platz, nämlich überall da wo man früher mit sed oder awk gearbeitet hat. Ich kann Dir nicht mehr folgen. So weit ich Bernd verstehe, scheint er Perl als sh/bash-Ersatz anzusehen. Ich teile diese Meinung.

Aus meiner Erfahrung heraus gibt es einen weiten Bereich von Programmen, die in Perl sehr einfach, in C aber sehr viel schwieriger umzusetzen sind. Richtig, "_einen_ weiten Bereich" - Das heist nichts anderes als "eine gewisse Klasse von Problemen in einem gewissen Kontext".

Das Problem daran: Dieser Bereich sieht je nach Problemklasse und Kontext völlig anders aus.

Der Unterschied ist so frappant, daß ich mich nur darüber wundern kann, daß Du ihn nicht siehst.

Wieder: Problemklasse und Kontext. In denen von dir bearbeiteten Problemen und in deinem Kontext scheint Perl Vorteile zu haben - in anderen Situationen (u.a. bei mir) sieht die Sache anders aus. Grundsatzdiskussionen zum Thema "Was ist die richtige Programmier-/Scriptsprache" sind deshalb grundsätzlich sinnlos, wenn man den Kontext nicht kennt. Wie schon so oft gesagt, "Eine universelle Script-/Programmiersprache" gibt es nicht. Um auf dein Beispiel zurückzukommen: Nimm dein String-Beispiel in einer C- und in einer Perl-Version und teste es in unterschiedlichen Umgebungen und Anwendungen: * Als Teil einer kleinen bis mittleren User-Applikation mit gemässigter Datenmenge unter Linux und anderen halbwegsmoderen Unixsystemen, Perl ist kein Problem, eine angemessene Problemlösung. * Auf der alten U*nix-Maschine. Perl wird zum Problem, weil "einfach zu fett". * Auf einem Embedded-System oder auf einem PDA. Entweder Perl nicht verfügbar, oder "zu fett", oder aber nicht einmal eine Shell-Umgebung vorhanden. * Das gleiche mit grossen Datenmengen/Datensätzen. Eine C-Implementierung ist dann weit überlegen. * Das gleiche in einer grossen Applikation: Perl wird sehr schnell unübersichtlich und fehleranfällig (Fehlende Typenstrenge, implizite Konvertierungen, Garbage-Collection, u.ä.). * Als Teil eines SysAdmin-Scriptes im Single-User Mode ohne /usr-Partition => Kein Perl verfügbar. ... Von persönlichen Kontexten (Know-How) und politisch/wirtschaftlichen Kontexten ("Muss in phython geschrieben werden") oder anderen technischen Überlegungen (ala "Prolog/Lisp wäre der Problemstellung angemessener") mal ganz abgesehen. Ralf

* Thorsten Haude schrieb am 08.Jun.2002:

* Ralf Corsepius [02-06-08 09:56]:

...

Am Sam, 2002-06-08 um 00.06 schrieb Thorsten Haude:

...

So weit ich Bernd verstehe, scheint er Perl als sh/bash-Ersatz anzusehen. Ich teile diese Meinung. Ne, eben nicht, er scheint C als sh/bash-Ersatz anzusehen. 20020604090137.GA2880@b.brodesser.dialin.t-online.de

Es ging um umfangreiche Skripte. Da habe ich geschrieben, daß man da auch oft gleich C nehmen könnte.

Der Bereich 'hochwertiger Ersatz für Shellskripte' gehört zu Perls Stärken und zu Cs Schwächen. Auf diesen Bereich bezieht sich die Diskussion und die obige Aussage.

Warum sollte ich Shellskripte ersetzen? Doch höchstens, wenn sie nicht schnell genung sind. Und dann nehme ich C.

...

Wie schon so oft gesagt, "Eine universelle Script-/Programmiersprache" gibt es nicht.

Ja.

Leider.

...

* Als Teil einer kleinen bis mittleren User-Applikation mit gemässigter Datenmenge unter Linux und anderen halbwegsmoderen Unixsystemen, Perl ist kein Problem, eine angemessene Problemlösung.

* Auf der alten U*nix-Maschine. Perl wird zum Problem, weil "einfach zu fett". Nein, denn ich setze es nicht als Applikation ein. Den Aufwand, diese kurze Funktion (parseFilename()) in C zu schreiben, und dann noch in einer Qualität, die bzgl. Bufferoverruns der von Perl entspricht, ist so groß, daß ich das Programm einige Tausend, vielleicht Millionen mal starten kann.

Was meinst Du mit parseFilename? Hört sich nach lex an.

...

* Auf einem Embedded-System oder auf einem PDA. Entweder Perl nicht verfügbar, oder "zu fett", oder aber nicht einmal eine Shell-Umgebung vorhanden. Jepp. Das ist auch keine Platz für Shellskripte.

...

* Das gleiche mit grossen Datenmengen/Datensätzen. Eine C-Implementierung ist dann weit überlegen. Kann stimmen, Perls Schwäche liegt aber vor allem beim Start.

Was ist mit vielen Dateideskriptoren, Prozessen, Pipes usw.?

...

* Das gleiche in einer grossen Applikation: Perl wird sehr schnell unübersichtlich und fehleranfällig (Fehlende Typenstrenge, implizite Konvertierungen, Garbage-Collection, u.ä.). Das muß nicht so sein, ist aber ein anderes Problem. Auch hier ist kein Platz für Shellskripte.

Es ist ein Problem von perl. So nett es scheinen mag, daß perl viele Möglichkeiten hat, und die Syntax sehr unterschiedlich aussehen kann. Wen es sich um ein Projekt mit vielen Programmierer handelt, dann wird es sehr schnell total unübersichtlich.

...

* Als Teil eines SysAdmin-Scriptes im Single-User Mode ohne /usr-Partition => Kein Perl verfügbar. Drum würde ich auch nur umfangreichere Sache damit machen, keine Kleinigkeiten.

Und umfangreiche Sachen kann man doch meist besser gleich mit C machen. Kleinigkeiten mit der bash. Sicherlich gibt es Bereiche, wo perl überlegen ist. Vor allem dort, wo man früher sed oder awk genommen hätte und mehr als ein Einzeiler ist. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9

* Thorsten Haude schrieb am 08.Jun.2002:

* Bernd Brodesser [02-06-08 14:00]:

...

Was meinst Du mit parseFilename? Hört sich nach lex an. Das war ein Beispiel, das mit Perl im Handumdrehen zu lösen ist, mit Shells oder C aber deutlich mehr Aufwand bedeutet. 20020606211031.GK988@eumel.yoo.net

Ja, bei sowas ist perl klar im Vorteil. Aber wenn man wirklich ein Parser braucht, dann macht man das lieber mit lex bzw. flex.

...

Und umfangreiche Sachen kann man doch meist besser gleich mit C machen. Kleinigkeiten mit der bash. Die Bash würde ich nun wirklich überhaupt nicht benutzen. Da hat man nichtmal den Vorteil der größeren Plattformunabhängigkeit. Was mit sh

Mit bash meinte ich sh. Original Bourne Shell wird man wohl kaum noch bekommen. Aber ist doch klar, daß man kompatibel bleiben sollte.

nicht geht, mache ich mit Perl, das läuft auf mehr Plattformen und ist einfacher. 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?

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. Ich habe doch geschrieben, es ging um umfangreiche Skripts. Und ab irgend ein Punkt ist es besser C zu nehmen. Was anderes habe ich nicht gesagt. Ein paar hunderttausend Zeilen in einem Skript halte ich nicht für Sinnvoll. Zehntausend wohl auch nicht. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0

Moin Moin, Am Samstag, 8. Juni 2002 18:52 schrieb Thorsten Haude:

* Bernd Brodesser [02-06-08 17:55]:

...

* Thorsten Haude schrieb am 08.Jun.2002:

...

* Bernd Brodesser [02-06-08 14:00]:

...

Was meinst Du mit parseFilename? Hört sich nach lex an.

Das war ein Beispiel, das mit Perl im Handumdrehen zu lösen ist, mit Shells oder C aber deutlich mehr Aufwand bedeutet. 20020606211031.GK988@eumel.yoo.net

Ja, bei sowas ist perl klar im Vorteil. Aber wenn man wirklich ein Parser braucht, dann macht man das lieber mit lex bzw. flex.

Es gibt da ein gutes Perl Modul, Jeeves z.B.! Ich nutze es um Header Datien in C/C++ zu generieren. SQL Strukturen kannst DU auch machen, eigentlich kannst Du damit alles generieren. Mit Jeeves kann man seine eigene Behelf-Sprache bauen:))

Ich hatte noch nie Probleme, bei denen ich an Lex gedacht hätte (das ich zugegeben auch kaum kenne), aber schon einige, bei dened Perl helfen konnte.

ACK!

...

...

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.

Im Endeffekt aber sehr schnell und zuverlässig.

...

...

begründet, darum wäre es nett, wenn Du mal ein Beispiel im Bereich Shellskripte nennst, bei dem C überlegen wäre.

ImageMagick zum Beispiel, wenn Du mit C/C++ Bilder generierst, ist das mit Sicherheit _schneller_ als Perl/Java und so. Das mache ich gerade auf der Arbeit, dort habe ich einige Vergleiche zwischen Java/Perl und C/C++ gemacht. Was mir besonders aufgefallen ist, daß kleine Programme mit Perl schneller laufen als Java ( vielleicht interessiert's ).

...

Überall dort wo es zeitkritisch wird.

ACK!!! Ciao Andre

Moin, * Bernd Brodesser [02-06-09 10:45]:

* Thorsten Haude schrieb am 08.Jun.2002:

...

* Bernd Brodesser [02-06-08 17:55]:

...

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, das steht da nicht.

...

...

...

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. Aber dann wird Deine Frage unsinnig. Sie lautet ja, nenne ein Beispiel im Bereich wo Shellskripte überlegen sind, bei dem C überlegen wäre. Ich würde Shellskripte nicht einsetzen, wenn es zeitkritisch wird.

Nimm etwa killall. Kein Problem dies mit ps, cut und grep als Shellskript zu schreiben. Aber es könnte nicht schnell genung sein. Dann ist es wohl doch ein Problem, denn in diesem Fall scheint der Zeitfaktor ein wesentlicher zu sein.

(Wo genau ist eigentlich das Problem?)

Ich kenne auch etwa basename und dirname als einfaches Shellskript. Aber offensichtlich ist es nicht immer schnell genung. Vorallem, wenn es extensiv benutzt wird, dann kann es ein Skript schon ganz schön langsam machen. Es muß also nicht immer irgendwas sehr umfanreiches sein. Solche Shellskripte sind an sich schon sinnvoll, man sollte aber im Blick behalten, wie sie eingesetzt werden. Ob man ein Shellskript als 'Funktion' in einem größeren Zusammenhang einzusetzt, sollte man sich genau überlegen.

Thorsten -- Once upon the time, the music industry had something to offer to us - they distributed the music we would have never heard without them. Now, they need laws that prevent us to do ourself what they do for money.

Am Son, 2002-06-09 um 15.25 schrieb Bernhard Walle:

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:

...

...

...

...

begründet, darum wäre es nett, wenn Du mal ein Beispiel im Bereich Shellskripte nennst, bei dem C überlegen wäre. Z.B. Binärdaten-Konvertierung.

Momentan fällt mir kein Shellscript ein, das sich damit befasst. Vermutlich, eben weil es nur sehr umständlich bis garnicht möglich ist.

...

...

...

Ü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. Genausogut kannst Du auf jedem unixoiden OS eine OpenSource-Shell deiner Wahl installieren (z.B. Bash, zsh, pdksh, tcsh) und deren Spezialitäten zur Neige ausreizen - Du hast ja eine einheitliche Umgebung.

Ansonsten ist "zeitkritisch" ein relativer Begriff: Ein Beispiel: autoconf/automake In Perl implementiert sind dabei: autom4te (autoconf > 2.50 unterlagertes Script). automake (> 8000 Zeilen Perl.). Ein autoconf/automake bootstrap/autogen.sh Lauf über einen (real existierenden) Source-Tree bestehend aus ca 9000 Quelldateien, ca. 90-100 configure-Scripten und ca. 900 Makefile.am dauert auf meinem PIII/1GHz ca. 20 Minuten. Nun probier das gleiche auf einer Sun/Sparc2, i486 ...

Und: Perl ist IMHO deutlich besser dokumentiert als die Shell. Tut mir leid, diese Meinung teile ich nicht - Grundwissen der Sh-Programmierung und zum Umgang mit "sed/awk/grep etc." gehört zum Grundwissen eines jeden Unix-Entwicklers. Darüberhinaus gibt es zur Shell-Programmierung ebenso wie zu Perl Dutzende von Büchern.

Ich persönlich finde die Perldoku äusserst unübersichtlich und für Anfänger genauso unverständlich wie die Bashdoku. Die Doku zu einzelnen Perl-Modulen ist von sehr unterschiedlicher Qualität, genauso wie die Qualität einzelner Perlmodule ist (Ja, es gibt gute Perlmodule, es gibt aber auch ebenso schlechte).

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, Sorry, aber ROTFL:

man perl [..] perl Perl overview (this section) perlfaq Perl frequently asked questions perltoc Perl documentation table of contents perlbook Perl book information perlsyn Perl syntax perldata Perl data structures perlop Perl operators and precedence perlsub Perl subroutines perlfunc Perl builtin functions [..ca 50-60 weitere Verweise auf Manpages gelöscht.] .. nun lass einen Pascal-Umsteiger nach REPEAT/UNTIL suchen ... .. oder versuch anhand der man-Pages, der Bedeutung folgender Zeilen in einem Module auf den Grund gehen: @ISA = qw(Exporter);

drittens kann ich Perl-Dokumentation in verschiedenen Formaten haben und viertens ist perldoc -f oder perldoc -q _sehr_ nützlich. man groff, man texinfo.

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. Auch das halte ich für nur mit Einschränkung richtig:

Eine Vielzahl von CPAN-Modulen müssen auch erst übersetzt werden und hängen direkt von C und/oder anderem ab. Zur Veranschaulichung: Probier doch mal das XML::LibXML-Module zu installieren (Ein sehr leistungsfähiges XML-Parser-Module): perl -m CPAN -e shell install XML::LibXML Vermutlich wird es Dich überraschen, was da alles hinterherkommt. :)

Man hat also deutlich mehr davon, Perl zu lernen als sich mit allen möglichen Shellskript- Helferchen auseinanderzusetzen. Siehe oben. An den "kleinen Helferlein" (grep, sed, awk, etc.) und den Grundlagen der Sh führt kein Weg vorbei.

Nein, Perl als einen sed-&-awk-Ersatz hinzustellen grenzt an eine Beleidigung. Ich würde es als Unix-Basic bezeichnen ;)

Im Ernst, für mich ist Perl eine Alternative zur sh für mittel-kleine Applikationen und für mittel-kleine Rapid-Prototyping-Geschichten. Ralf PS.: Auch wenn es hier anders klingen mag, auch ich verwende mit Perl, und ziehe es ab einem gewissen Programm-Umfang Bash-Scripten vor. Nur, sobald es mal etwas komplexer wurde, habe ich bisher noch immer auf C oder C++ gewechselt.

Thorsten Haude schrieb:

* Ralf Corsepius [02-06-10 08:00]:

...

An den "kleinen Helferlein" (grep, sed, awk, etc.) und den Grundlagen der Sh führt kein Weg vorbei. Doch, Perl.

Quatsch! Ich schreibe doch kein Perl-Script, nur weil ich irgendeine Kleinigkeit mal eben haben will! Ich habe hier oft Kommandos mit zig pipes! command | grep irgendwas | awk .... | xargs .... Das ist in 5 sec. hingeschrieben! Bei kritischen Dingen mache ich zuerst noch eine umleitung in eine Datei um dann erst die Aktionen durchzuführen (Also statt xargs!), aber immer erst perl-scripte schreiben? Das halte ich für "suboptimal". Aber natürlich muss man das nicht alles machen. Man kann es auch in Perl machen oder in C oder in Assembler! Aber gewisse Dinge sind einfache Grundlagen von Unix und von einem Systemadmin erwarte ich diese einfach! Generell soll jeder die Sprache nehmen, die er kann und die ihm liegt! Jemand, der keine Ahnung von Shell Skripten und so hat, der wird natürlich mit Perl deutlich schneller zum Ziel kommen (wenn er denn Perl kann!). Ein C++ Spezialist, der weder von einer Shell noch von Perl Ahnung hat, wird schnell eine C++ Lösung entwerfen! Aber ich würde mir z.B. für die Administration keinen C++ Entwickler holen :) Und wenn ich als C++ Entwickler Unix Rechner administrieren müsste, dann würde ich mir auch durchaus die Unix-Syntax anschauen :) Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

* Thorsten Haude schrieb am 10.Jun.2002:

* Konrad Neitzel [02-06-10 07:24]:

...

Thorsten Haude schrieb:

...

* Ralf Corsepius [02-06-10 08:00]:

...

...

...

An den "kleinen Helferlein" (grep, sed, awk, etc.) und den Grundlagen der Sh führt kein Weg vorbei.

...

...

Doch, Perl.

...

Quatsch! Ich schreibe doch kein Perl-Script, nur weil ich irgendeine Kleinigkeit mal eben haben will!

ACK!

...

Ich habe hier oft Kommandos mit zig pipes!

command | grep irgendwas | awk .... | xargs ....

Das ist in 5 sec. hingeschrieben!

ACK!

Es sei denn, man kennt awk nicht. Ich lerne doch nicht ein eher komplexes Tool, wenn ich ein anderes kenne, das eine Obermenge der Funktionalität bietet.

awk und auch sed, würd ich auch keinem mehr empfehlen in vollem Umfang zu lernen. Da ist perl besser. Aber für Einzeiler taugen die beiden immer noch. Nochwas zu Konrad, das jetzt leider gelöscht wurde, aber egal: Ein Sysadmin muß nicht unbedingt perl können, vielleicht noch nichtmal C, aber mit der sh sollte er schon umgehen können. Da führt kein Weg vorbei.

(Übrigens benutze ich selbstverständlich grep.)

Übrigens benutze ich selbstverständlich perl Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4

Hallo, On Mon, 10 Jun 2002, Bernhard Walle wrote:

Grep benutze ich natürlich auch, genauso wie cut, head, tail oder selten sed.

Wobei letzteres erstere 4 ersetzen kann. (Ich erinnere nur an die Pipe-Orgien (teilweise sogar mit Perl) beim herausfinden der aktuellen dyn.-IP... Dabei tut's ein einzelnes sed, such mal nach 'dynip.sh' von mir im Archiv ;) -dnh -- Boring is better. Humdrum is marvelous. Dullsville is desirable. -- Mike Andrews in asr

On Mon, 10 Jun 2002 at 08:00 (+0200), Ralf Corsepius wrote:

Am Son, 2002-06-09 um 15.25 schrieb Bernhard Walle:

...

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:

...

Und: Perl ist IMHO deutlich besser dokumentiert als die Shell. Tut mir leid, diese Meinung teile ich nicht - Grundwissen der Sh-Programmierung und zum Umgang mit "sed/awk/grep etc." gehört zum Grundwissen eines jeden Unix-Entwicklers. Darüberhinaus gibt es zur Shell-Programmierung ebenso wie zu Perl Dutzende von Büchern.

Ich habe sogar eines über Shellprogrammierung. Awk wird darin übrigens gar nicht erwähnt. So wichtig kann's wohl nicht sein. Im übrigen teile ich Deine Meinung, dass man etwas Ahnung von sh/grep oder vielleicht noch sed haben sollte; awk gehört dazu meiner Meinung nach allerdings nicht. Wenn es so komplex wird, dass ich awk brauche, dann kann ich gleich Perl nehmen.

...

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, Sorry, aber ROTFL:

man perl [..] perl Perl overview (this section) perlfaq Perl frequently asked questions perltoc Perl documentation table of contents perlbook Perl book information

perlsyn Perl syntax perldata Perl data structures perlop Perl operators and precedence perlsub Perl subroutines perlfunc Perl builtin functions

[..ca 50-60 weitere Verweise auf Manpages gelöscht.]

Eben. Es wird auf verschiedene Manpages aufgeteilt.

...

drittens kann ich Perl-Dokumentation in verschiedenen Formaten haben und viertens ist perldoc -f oder perldoc -q _sehr_ nützlich. man groff, man texinfo.

Zu HTML habe ich in groff nichts gefunden. Und texinfo ist nicht für Manpages (meines Wissens) sondern für Infopages.

...

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. Auch das halte ich für nur mit Einschränkung richtig:

Eine Vielzahl von CPAN-Modulen müssen auch erst übersetzt werden und hängen direkt von C und/oder anderem ab.

Schon klar.

...

Man hat also deutlich mehr davon, Perl zu lernen als sich mit allen möglichen Shellskript- Helferchen auseinanderzusetzen. Siehe oben. An den "kleinen Helferlein" (grep, sed, awk, etc.) und den Grundlagen der Sh führt kein Weg vorbei.

Doch: Perl -- zumindest an awk oder sed. Zu Bash/sh: ACK. Gruß, Bernhard -- "My great concern is not whether you have failed, but whether you are content with your failure." -- Abraham Lincoln

Am Mon, 2002-06-10 um 17.24 schrieb Bernhard Walle:

On Mon, 10 Jun 2002 at 08:00 (+0200), Ralf Corsepius wrote:

...

Am Son, 2002-06-09 um 15.25 schrieb Bernhard Walle:

...

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:

...

Und: Perl ist IMHO deutlich besser dokumentiert als die Shell. Tut mir leid, diese Meinung teile ich nicht - Grundwissen der Sh-Programmierung und zum Umgang mit "sed/awk/grep etc." gehört zum Grundwissen eines jeden Unix-Entwicklers. Darüberhinaus gibt es zur Shell-Programmierung ebenso wie zu Perl Dutzende von Büchern.

Ich habe sogar eines über Shellprogrammierung. Awk wird darin übrigens gar nicht erwähnt. So wichtig kann's wohl nicht sein. <*g*> geht mir genauso, awk verwende ich so gut wie nicht, dafür aber noch eine ganze Reihe andere "kleiner Helferlein".

Im übrigen teile ich Deine Meinung, dass man etwas Ahnung von sh/grep oder vielleicht noch sed haben sollte; awk gehört dazu meiner Meinung nach allerdings nicht. Wenn es so komplex wird, dass ich awk brauche, dann kann ich gleich Perl nehmen. Jep.

...

...

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, Sorry, aber ROTFL:

man perl [..] perl Perl overview (this section) perlfaq Perl frequently asked questions perltoc Perl documentation table of contents perlbook Perl book information

perlsyn Perl syntax perldata Perl data structures perlop Perl operators and precedence perlsub Perl subroutines perlfunc Perl builtin functions

[..ca 50-60 weitere Verweise auf Manpages gelöscht.]

Eben. Es wird auf verschiedene Manpages aufgeteilt. Weil ich Perl nicht allzu oft verwende, suche mich jedesmal zu Tode, wenn es um Details geht ;)

...

...

drittens kann ich Perl-Dokumentation in verschiedenen Formaten haben und viertens ist perldoc -f oder perldoc -q _sehr_ nützlich. man groff, man texinfo.

Zu HTML habe ich in groff nichts gefunden. Man pages sind in *roff geschrieben und lassen ganz hervorragend in in einer ganzen Reihe von Formaten ausdrucken.

Aus man groff: groff is a front-end to the groff document formatting system. Normally it runs the troff program and a postproces­ sor appropriate for the selected device. Available devices are: [..] html To produce HTML output. [..] EXAMPLE To print the man page foo.1 to the standard output using the latin-1 output device and less as the pager, the fol­ lowing command can be used: groff -mandoc -Tlatin1 foo.1 | less Alternatively, you can say groff -m mandoc -Tlatin1 foo.1 | less [..] Also zcat /usr/share/man/man1/bash.1.gz | \ groff -mandoc -Thtml > /tmp/bash.html [groff gehört auch zu den kleinen Helferlein, die man zumindest ab zu und zu mal braucht, zcat gzip, bzip2, tar, uvm. sowieso ..]

Und texinfo ist nicht für Manpages (meines Wissens) sondern für Infopages. Richtig. Die Quellen der bash Doku sind *texinfo Dateien. Diese lassen sich in eine Vielzahl von Datenformaten formatieren, anzeigen und ausdrucken, darunter auch html und die sonst üblichen TeX basierten Formate

Siehe auch /usr/share/doc/packages/bash auf deiner Festplatte bzw. http://localhost/doc/packages/bash ;)

...

...

Man hat also deutlich mehr davon, Perl zu lernen als sich mit allen möglichen Shellskript- Helferchen auseinanderzusetzen. Siehe oben. An den "kleinen Helferlein" (grep, sed, awk, etc.) und den Grundlagen der Sh führt kein Weg vorbei.

Doch: Perl -- zumindest an awk oder sed. Perl statt sed? Nun ja, Kanonen auf Spatzen.

Gerade in Kombination mit find und grep ist sed äusserst mächtig: Etwas in diese Art kommt zumindest bei mehrfach wöchentlich vor: # find -name '*.[ch]' -exec grep -l muster0 {} \; \ | while do read a; do \ sed -e 's,muster1,etwas,' \ -e '/muster2/d' \ < $a > $a~; mv $a~ $a; done Ralf

Hallo Ralf, * Am 08.06.2002 um 09:56 Uhr schrieb Ralf Corsepius:

* Das gleiche in einer grossen Applikation: Perl wird sehr schnell unübersichtlich und fehleranfällig (Fehlende Typenstrenge, implizite Konvertierungen, Garbage-Collection, u.ä.).

warum hälts Du eine Garbage-Collection für fehleranfällig? Im Gegenteil...es wird nur der Speicher freigegeben, der nicht mehr benötigt wird. Speicherleichen (Freigabe wurde vergessen) bzw. Zugriffe ins Nichts (zu frühe Freigabe) kommen nicht mehr vor - ein Traum für C-Progammierer ;-) -Jürgen -- Sind Sie im Zweifel, murmeln Sie. Sind Sie in Schwierigkeiten delegieren Sie. / Registered Linux-User #130804 http://counter.li.org \ \ Linux Stammtisch Bremerhaven http://linux.hs-bremerhaven.de /

IMHO kommt das auf die Sprache an! Perl finde ich noch OK, aber Java macht damit recht komische Dinge. Einige Objekt werden eben nur freigegeben, wenn Java dazu Bock hat (oder auch gar nicht).

Tschuldige - aber das ist kompletter Unsinn. Die Techniken der Garbage Collection sind seit Jahren bekannt und erprobt, und werden in allen Sprachen einigermassen einheitlich verwendet. Wann in Java welche Objekte freigegeben werden ist klar dokumentiert und wird auch eingehalten. Die GC hat mit der Sprache an sich eh nichts zu tun sondern mit der Implementierung. Für Java gibt es eine Reihe verschiedener VMs, z.B. von IBM, Sun, MS, BEA, und anderen. Bei keiner sind mir fundamentale Probleme mit der GC bekannt. Wenn man sich die Namen, die Entwicklungszeit und den Millionenfachen Einsatz anschaut dann gehört Java GC sicher zum Stabilsten was die Branche zu bieten hat.

Hi, From: Juergen Schwarting

* Am 09.06.2002 um 02:13 Uhr schrieb Andre Heine:

...

Einige Objekt werden eben nur freigegeben, wenn Java dazu Bock hat (oder auch gar nicht).

Da sollte die Garbage-Collection um einiges verbessert werden.

Da benutze ich lieber "delete", wenn etwas nicht freigegeben wird kann ich mir selber an die Nase fassen :)))

schau Dir mal System.gc() an. Mit dieser Methode kann man explizit der VM mitteilen, daß die Garbage Collection ausgeführt werden soll ;-)

Alles schon probiert, Java führt das manchmal (will sogar sagen, Java macht das frei nach Schnauze!). eben sehr verzögert aus. Java läuft ja in eigenen Threads ab, darum passiert öfters mal dieses Verhalten. DIese Info's stehen sogar in JAVA in a Nutshell und Java Examples. Auch bei der Methode finalize() kann es passieren, das die Anweisungen nicht ausgeführt werden! Weil eben Java dort interne/ eigene Sachen macht. Ciao Andre

Moin Moin, From: Juergen Schwarting

* Am 10.06.2002 um 11:09 Uhr schrieb Andre Heine:

...

From: Juergen Schwarting

...

schau Dir mal System.gc() an. Mit dieser Methode kann man explizit der VM mitteilen, daß die Garbage Collection ausgeführt werden soll ;-)

Alles schon probiert, Java führt das manchmal (will sogar sagen, Java macht das frei nach Schnauze!). eben sehr verzögert aus. Java läuft ja in eigenen Threads ab, darum passiert öfters mal dieses Verhalten.

sicher?

In meinem Buch (OK, ist älter Java1.2) steht, daß dies auch "EinObject = null" dies erledigen soll. Dabei wird ein Object explicit gelöscht, tut's aber nicht! Wenn ich in C/C++ delete EinObject mache, funktioniert dies ganze Sache. Natrülich brauche ich dann einen Destruktor.

Ich verstehe die Doku so, daß der Garbage Collector durch diesen Methodenaufruf dazu animiert wird die gesamte Liste verfügbarer Objekte abzuklappern und alle mit LinkCounter = 0 freizugeben. Der explizite Aufruf wird sogar empfohlen wenn größere Speicherbereiche freizugeben sind, z.B. nachdem eine dynamische Liste gelöscht wurde.

Java 1.4??

...

DIese Info's stehen sogar in JAVA in a Nutshell und Java Examples. Auch bei der Methode finalize() kann es passieren, das die Anweisungen nicht ausgeführt werden! Weil eben Java dort interne/ eigene Sachen macht.

Der Garbage Collector läuft in einem eigenständigen Thread mit geringer Priorität. Wenn man kurzfristig Platz braucht, sollte man es dem GC auch mitteilen (System.gc()).

Solange allerdings noch Verweise auf das Objekt existieren passiert ohnehin nichts.

Aha, warum löscht Java diese dann nicht? Muß ich etwa doch alles selber machen? ( Das wäre für mich nicht einmal schlimm). Scheinbar werden durch den eigenen Thread einige Speicherbereiche sehr spät entfernt. Java meint das das ruhig warten kann. _Kann_ es eben nicht!

Das finalize() nicht zwingend ausgeführt wird, liegt sicherlich auch daran, daß am Programmende der GC noch nicht alles abgeklappert hat und hierzu auch keine Notwendigkeit mehr besteht.

Ich selber nehme eben darum das 'Freigeben von Speicher' selbst in die Hand. So schön ein "Garbage Collector" auch ist, gegen die internen abläufe kannst Du erst mal gar nichts machen. Und Java bleibt mir in einigen Dingen ein Rätsel ;(( Ciao Andre

Hallo Juergen, Am Montag, 10. Juni 2002 16:08 schrieb Juergen Schwarting:

* Am 10.06.2002 um 13:20 Uhr schrieb Andre Heine: damit löscht man aber kein Objekt, sondern weist nur der Objektvariable den Wert 'null' zu. Solange noch weitere Verweise auf das Objekt existieren, wird es natürlich auch nicht freigegeben (dem GC-sei-Dank ;).

Hmmm, hier könnte bei mir der Fehler liegen. Folgendes Szenario: Wir haben ein VB-Script( sorry ist Windows und _OT_) und ein JavaBean. Beide nutzen OLE um miteinander kommunizieren. IMHO ist OLE ein Schnittstelle, die es erlaubt ein Object im Speicher anzulegen, womit man mit unterschiedlichsten Sprachen darauf zugreifen kann. Wir starten über ein VB-Script das JavaBean. Java startet die darin enthaltene Anwendung. Diese Applikation läuft in einer While-Schleife, damit die Java App. am leben bleibt und nicht sofort wieder zu VB springt. Nur Java kann die whileschleife beenden, eine Anweisung später will ich diese Java App. explicit aus dem Speicher entfernen. Das klappt zur Zeit nur mit "System.exit(0)". Leider wird so auch sofort VB Beendet. ( Das darf nicht passieren, laut SAP) Wenn nun die While-Schleife durch eine Java-Methode abgebrochen wird, soll wieder zu VB gesprungen werden. (Klappt alles wunderbar) Hier liegt der Knackpunkt! Hält VB da etwa noch einen Verweis ( über OLE ) auf das Java-Objekt??? Selbst wenn ich über OLE von Vb aus das Objekt freigeben will, passiert nichts. (Außer das Windows durchdreht) Mein Gedanke ist nun, daß Java die Ressourcen nicht korrekt freistellt und VB das Object nicht zerstören kann. Ich sehe, nachdem Java zu VB zurückkehrt und VB längst beendet ist immer noch "Zombies" im Task Manager, die ich von Hand killen muß. Diese Zombies sind nach einem System.exit(0) nicht mehr da, darum glaube ich an einen Fehler auf der Java Seite. Fehler ist falsch ausgedrückt, aber in C/C++ wird IMHO eben alles zerstört, auch wenn noch Objekte darauf zugreifen.

...

...

Der Garbage Collector läuft in einem eigenständigen Thread mit geringer Priorität. Wenn man kurzfristig Platz braucht, sollte man es dem GC auch mitteilen (System.gc()).

Wenn OLE noch als Verweis gilt, liegt es ja nahe das Java den Speicher nicht freigibt. Selbst VB gibt die Ressourcen nicht frei. Sorry für dieses Mega OT... Ciao Andre

* Thorsten Haude schrieb am 06.Jun.2002:

Moin,

* Bernd Brodesser [02-06-06 10:27]:

...

* Thorsten Haude schrieb am 06.Jun.2002:

...

* Bernhard Walle [02-06-05 23:50]:

...

Außerdem: Ich weiß, wie man Google bedient und ich habe auch den Link schon aufgerufen, bevor ich obige Mail verfasst habe. Allerdings: Was interessieren mich Funktionen, die es (unter Linux) gar nicht gibt und die offensichtlich auch in keinen Standards (weder POSIX noch ANSI/ISO C** noch sonstwas) enthalten sind? Der Unterschied soll (!) Dich nur darüber nachdenken lassen, warum evtl. manche Leute behaupten, daß Stringoperationen in Perl einfacher zu machen sind als in C. Die Tatsache, daß strlcpy() nicht auf allen Plattformen zur Verfügung steht, ist ein weiteres Argument dafür. Wahnsinn.

strncpy (newstring,oldstring,n); newstring [n-1] = '\0'; Du hast vergessen, Speicher zu allozieren.

Nein, der must schon vorher allokiert worden sein.

Jetzt eine Funktion; wie sieht das in C aus: - - - Schnipp - - - sub weekDay { return (localtime)[6]; } - - - Schnapp - - -

Schreib Dir eine Funkeion dazu. Vielleicht gibt es auch eine.

...

Schön. Und warum wird es in C wohl nicht so gemacht? Weil C älter ist und andere Ziele hat.

Quark, ja. C ist eine Maschienennahe Sprache. Wenn Du eien zeitkritische Funktion haben möchtest, dann sollte man sie in C schreiben. C hat gegenüber Assambler den Vorteil, das es Maschienenunabhängig ist. Bernd -- Welches Buch ist zu empfehlen? Schon mal bei SuSE vorbeigesehen? http://www.suse.de/de/products/books/index.html oder die Empfehlungen der SuSE-Entwickler auf dem eigenen Rechner? file:///usr/share/doc/sdb/de/html/literatur.html |Zufallssignatur 5

On Wed, 05 Jun 2002 at 00:22 (+0200), Bernd Brodesser wrote:

* Thorsten Haude schrieb am 04.Jun.2002:

...

* Bernd Brodesser [02-06-04 11:01]:

...

* Thorsten Haude schrieb am 03.Jun.2002:

...

...

Aber dann kanst Du gleich C nehmen. Auch nicht komplizierter, aber schneller in der Ausführung. Ich gehe davon aus, daß Du schonmal Stringoperationen in C gemacht hast, darum verstehe ich Deine Aussage nicht.

Ich habe schonmal Stringoperationen in C gemacht und weiß nicht, wo das Problem sein soll?

Hm, ich kann mir für diese Aussage nur drei Begründungen vorstellen: a) Du bist außerirdisch. b) Du hast noch nie etwas kompliziertere Stringoperationen in C programmiert. c) Du programmierst in Perl wie in C. Alleine schon die Tatsache, dass ich mich bei Perl um keinen Speicher kümmern muss (also malloc() & Co.) beschleunigt die Entwicklung ungemein. Gruß, Bernhard -- I couldn't give [Bill Gates] advice in business and he couldn't give me advice in technology. -- Linus Benedict Torvalds

On Wed, 05 Jun 2002 at 12:58 (+0200), Bernd Brodesser wrote:

* Bernhard Walle schrieb am 05.Jun.2002:

...

Hm, ich kann mir für diese Aussage nur drei Begründungen vorstellen:

a) Du bist außerirdisch. b) Du hast noch nie etwas kompliziertere Stringoperationen in C programmiert. c) Du programmierst in Perl wie in C.

Alleine schon die Tatsache, dass ich mich bei Perl um keinen Speicher kümmern muss (also malloc() & Co.) beschleunigt die Entwicklung ungemein.

Ist in C oft auch überflüssig. Nimm irgend was großes statisches.

Besonders speichersparend ist das aber nicht. Und selbst dann muss ich immer darauf aufpassen, dass ich nicht über meinen Speicher hinausschreibe, also z. B. strncpy statt strcpy verwenden etc. Ich habe nicht behauptet, dass C schlecht sei, aber für schnell mal ein Skript zur Systemadministration ist es einfach ungeeignet. Alleine schon deshalb, weil es keine Skriptsprache ist. Gruß, Bernhard -- Der Rechner von heute stuerzt ja schon ab, bevor man ihn ueberhaupt eingeschaltet hat. Das ist dann energiesparend und deshalb kein Bug sondern ein Feature.

Moin, * Bernd Brodesser [02-06-05 12:58]:

* Bernhard Walle schrieb am 05.Jun.2002:

...

Hm, ich kann mir für diese Aussage nur drei Begründungen vorstellen:

a) Du bist außerirdisch. b) Du hast noch nie etwas kompliziertere Stringoperationen in C programmiert. c) Du programmierst in Perl wie in C.

Alleine schon die Tatsache, dass ich mich bei Perl um keinen Speicher kümmern muss (also malloc() & Co.) beschleunigt die Entwicklung ungemein. Ist in C oft auch überflüssig. Ja, und oft eben auch nicht. Ich habe gerade eine Funktion für NEdit fertiggestellt, in der Strings eine wichtige Rolle spielen. Der Pseudocode sah so aus: if (isSet($NEDIT_HOME)) if (!exists($NEDIT_HOME)) create($NEDIT_HOME) use($NEDIT_HOME/nedit.rc, $NEDIT_HOME/nedit.history, $NEDIT_HOME/autoload.nm) else if (isFile(.nedit)) use(~/.nedit, ~/.neditdb, ~/.neditmacro) else if (!exists(~/.nedit)) create(~/.nedit) use(~/.nedit/nedit.rc, ~/.nedit/nedit.history, ~/.nedit/autoload.nm)

In Perl ersetzt man '$NEDIT_HOME' durch '$ENV{NEDIT_HOME}' und ist schon fast am Ziel, weil man natürlich eine Liste zurückgibt. In C sind es vier Fuinktionen, (einschließlich der Kommentare) 156 Zeilen, fast 5kB.

Nimm irgend was großes statisches. Oft besser, als den Speicherplatz dynamisch zu verwalten. Gilt natürlich nicht immer. Aber da wo man es macht, da sollte man es einkapseln, so daß es nur an einer Stelle gemacht wird, oder zumindest an wenige. Hat den Vorteil, daß man weiß was man frei geben muß. Ja, man kann in C programmieren, das ist unstrittig.

Thorsten -- Once upon the time, the music industry had something to offer to us - they distributed the music we would have never heard without them. Now, they need laws that prevent us to do ourself what they do for money.

Moin, * Ralf Corsepius [02-06-03 09:25]:

Am Don, 2002-05-30 um 23.30 schrieb Thorsten Haude:

...

* T. Hantke [02-05-30 22:58]:

...

welche Shell für welchen Zweck ist am besten zu verwenden? Für interaktive Shells ist die Zsh die beste Wahl, für Skripte Perl. Was verführt Dich zu dieser Aussage? Erfahrung mit unterschiedlichen Shells und Perl. Interessierst Du Dich für Details?

Verschiedene Versionen der Zsh sind als höchst problematisch bekannt (Die Zsh als Systemshell von OX X ist _der_ Grund, warum OS X User grosse Probleme mit autoconf u.Co. haben). Das kenne ich nicht, habe auch nie davon gehört. Bei mir läuft alles glatt (SuSE, Woody und Solaris).

Perl ist für gewisse Anwendungsfälle zweckmässig, für andere Fälle wiederum nicht. Klar. Insgesamt halte ich Perl aber für die beste Wahl für nicht-triviale Probleme in diesem Bereich.

Thorsten -- Intolerant people should be shot.

Moin, * Ralf Corsepius [02-06-04 01:10]:

Am Mon, 2002-06-03 um 21.45 schrieb Thorsten Haude:

...

* Ralf Corsepius [02-06-03 09:25]:

...

Verschiedene Versionen der Zsh sind als höchst problematisch bekannt (Die Zsh als Systemshell von OX X ist _der_ Grund, warum OS X User grosse Probleme mit autoconf u.Co. haben). Das kenne ich nicht, habe auch nie davon gehört. Darwin/OS X (Alternatives, ziemlich weit verbreitetes OS für MACs) verwendet zsh-3.x als Systemshell (/bin/sh == zsh-3.0.x). Äh ja, von OS X habe ich schon gehört, nur benutzt habe ich es noch nicht. Gehört habe ich noch nicht von den Fehlern.

...

Bei mir läuft alles glatt (SuSE, Woody und Solaris). zsh-4 nehme ich an ;) Allerdings. Also sind die Fehler bei Version 4 offiziell behoben? Dann solltest Du mal einen längeren Blick darauf werfen, interaktiv hat sie der Bash einiges voraus.

Thorsten -- Trying to make bits uncopyable is like trying to make water not wet. The sooner people accept this, and build business models that take this into account, the sooner people will start making money again. - Bruce Schneier

Moin, * Ralf Corsepius [02-06-05 06:00]:

Doch wer will es schon wagen, Usern zu ernsthaft empfehlen, die Systemshell durch eine andere zu ersetzen? Meinst Du mit Systemshell irgendwas besonderes? Als User benutze ich ausschließlich die Zsh, als root nur deswegen nicht, weil ich mir die Mühe nicht machen will, die Besonderheiten abzubilden. Dazu mache ich zu wenig als root.

Thorsten -- It's psychosomatic. You need a lobotomy. I'll get a saw. - Calvin

Ralf Corsepius schrieb am Mon, Jun 03, 2002 at 09:25:50AM +0200:

Am Don, 2002-05-30 um 23.30 schrieb Thorsten Haude:

Verschiedene Versionen der Zsh sind als höchst problematisch bekannt (Die Zsh als Systemshell von OX X ist _der_ Grund, warum OS X User grosse Probleme mit autoconf u.Co. haben).

Die Standard-Shell von MacOS X ist aber IMHO die tcsh... Gruß, Christian -- Christian Schmidt | Germany | christian@siebenbergen.de No HTML Mails, please!! http://lernst.de/zitieren/kriegst.de/antworten/

Ralf Corsepius schrieb am Tue, Jun 04, 2002 at 01:10:55AM +0200:

Am Mon, 2002-06-03 um 23.16 schrieb Christian Schmidt:

...

Die Standard-Shell von MacOS X ist aber IMHO die tcsh...

Ohne es aus eigener Erfahrung zu kennen, beziehe ich mich auf Darwin/OS X.

Auf was denn nun? Darwin oder MacOS X? <Spitzfindig> Mit "Darwin" ist nur der Open-Source-Kern des Apple-Betriebssystems gemeint. "MacOS X" bezeichnet das ganze System, also Darwin plus die proprietären "Beigaben" von Apple (z.B. Aqua). </Spitzfindig> Gruß, Christian -- Christian Schmidt | Germany | christian@siebenbergen.de No HTML Mails, please!! http://lernst.de/zitieren/kriegst.de/antworten/

Hallo Thorsten, * Am 03.06.2002 um 22:04 Uhr schrieb T. Hantke:

suche eigentlich eine Shell, die ich einem Benutzer zuordnen kann, die nur email-Abfragen ermöglicht.

Sprich FTP Zugriff etc. muss generell untersagt sein.

man bash `-> Stichwort: RESTRICTED SHELL damit wird sich sicherlich was machen lassen ;) -Jürgen -- Die letzten Worte eines E-Gitarrenspielers: "Gib noch etwas Saft drauf!" / Registered Linux-User #130804 http://counter.li.org \ \ Linux Stammtisch Bremerhaven http://linux.hs-bremerhaven.de /