Moin Alexander,
Exakt dort. How to install ucspi-tcp.
Die daemontools solltest Du auch kennen, die machen das Schreiben eines Daemons samt zuverlässigem Logger zu einem Kinderspiel.
Vielen Dank, Lesezeichen ist gesetzt, für den Fall der Fälle (Dämonen gehören normalerweise nicht zu meinem Tagesgeschäft).
Für einen trivialen Daemon kommst Du mit 10 Zeilen Shell-Script aus. Siehe auch the djb way.
Muss ich mir mal im Detail anschauen, denn das Symlinken und die Arbeit mit relativen Pfaden wollen geübt sein.
(BTW: Wie bekomme ich denn unter Unix/Linux den kompletten Pfad eines ausgeführten Programms?
$0
oder argv[0] in C enthalten nur den Namen, wie er auf der Konsole eingegeben wird.)Im Zweifel gar nicht.
Viele, aber nicht alle Unixe haben ein /proc-Dateisystem, von denen haben wiederum einige den Symlink /proc/self, andere nicht, dort mußt Du Dir die PID über getpid() besorgen. Schließlich findest Du in /proc/self bzw. /proc/$PID gelegentlich einen Symlink, der auf das zum Prozess gehörende Executable zeigt. Unter Linux heißt der Symlink exe, andere Unixe haben andere Namen. /proc muß übrigens nicht zwingend gemountet sein, und andere Unixe verstecken diese Information auch gerne mal an anderer Stelle.
Mac OS X z.B. scheint kein /proc zu kennen.
Übrigens: Rate mal, was folgendes Programm unter Linux ausspuckt. Und zwar egal, wie Du es aufrufst. Nicht mogeln! Erst mal aufschreiben, dann ausprobieren:
#!/usr/bin/perl
print readlink("/proc/self/exe"),"\n";
Wenn ich [readlink](http://perldoc.perl.org/functions/exec.html) richtig verstanden habe, gibt die Funktion das Ziel eines Symlinks zurück. Jetzt wäre nur noch die Frage, welches die zum Prozess gehörende Executable ist. Nachdem ich gerade ein wenig mit ps(1) herum gespielt habe, teilt #! in der ersten Zeile einer ausführbaren Datei der Shell mit: Nimm den folgenden Pfad bis zum Zeilenende als Interpreter dieser Datei. Genau das zeigt ps auch an.
(Ein recht kurzes Programm, das sich selbst ausgibt: #!/bin/cat)
> Du suchst den absoluten Pfad des aktuellen Scripts, und der ist nicht immer leicht zu ermitteln. [FindBin](http://search.cpan.org/perldoc?FindBin) schafft das oft, aber nicht immer. Einige Probleme sind in der Doku beschrieben, aber wohl nicht alle.
~~~perl
#!/usr/bin/perl -Tw
use strict;
use FindBin;
print $FindBin::Script, ' ', $FindBin::RealScript, "\n"
$ ./f
f f
$ $PWD/f
f f
Sollte da nicht etwas Anderes herauskommen?
Genau aus diesem Grund sollte man sicherheitskritischen Code nicht alleine konzipieren oder schreiben, und schon gar nicht "zwischen Tür und Angel". Man übersieht so etwas viel zu leicht.
Deshalb gibt es ja auch das SELFHTML-Forum ;-)
Was passiert, wenn exec() fehlschlägt?
Sofern -T nicht zuschlägt, läuft das Programm weiter. In diesem Falle wäre also exec @args or die $!
die richtige Wahl – „beende dich oder sterbe“.
In Deinem kleinen Script rennst Du in ...
my $socket = new IO::Socket::INET (
Listen => 5,
LocalPort => $port,
Proto => 'tcp',
Reuse => 1,
);
die $! unless $socket;
>
> ... rein. Und das fällt unter Linux wegen $port<1024 fürchterlich auf die Nase. Glück gehabt. ;-)
Und Windows interessiert mich an dieser Stelle auch gar nicht.
> Wieso schreibst Du eigentlich `die $! unless $socket`{:.language-perl}? Erstens ist das nicht das gewohnte Pattern `... or die`{:.language-perl}, zweitens fehlt da noch Text.
Was denn für Text? Das Programm basiert auf einem Projekt noch aus der Schulzeit, was schon etliche Jahre her ist.
> Und die Indirect Object Notation `$object=new CLASSNAME (@args);`{:.language-perl} sollte man sich auch verkneifen, weil die nicht immer eindeutig ist und daher mehr Arbeit beim Parsen macht.
Wie jetzt?
Viele Grüße,
Robert