Kylix - Linux - Befehl ausführen

[Pump3r]

Hi, ich hab jetzt Kylix 3 installiert, nun wollte ich mal was ganz einfaches schreiben.
Ich würd gerne ne mysql sicherung machen diese dann packen und wegschieben . . .
Nur häng ich da an nem kleinen Problem.
Wie sag ich Linux das es einen Befehl ausführt?
Ich mein unter Windows würd ich das jetzt angehen:
uses: ShellAPI

und dann halt: ShellExecute(Application.Handle,'open',PChar( . . . .

wie mach ich sowas unter linux?
zb einen ganz einfachen befehl wie die console öffnen?


gruß Pump

[Pump3r]

ah hab was gefunden . . libc

[Frickeldrecktuxer_TM]

Da gibt es prinzipiell mehrere Möglichkeiten.
Die grundlegenste ist ein eigner fork() in deinem Programm und anschließendes Aufrufen von execve() (oder eines der execve()-Frontends) und im Hauptprozess auf das Beendes des Childprozesses warten. Das wäre die POSIX-konforme Lösung, aber denkbar kompliziert im Vergleich zu ShellExecute(), dafür aber sicher.
Wenn du willst, daß dein Programm weiterläuft, während das andere Programm läuft, könntest du popen() benutzen und am Ende deines Programmes lediglich um aufzuräumen ein pclose() auf das zurückgegebene FILE machen. Dadurch kann dein Programm weiterarbeiten, während das andere Programm ebenfalls läuft. Sobald du aber pclose() aufrufst, wird auf das Ende des Kindprozesses gewartet, und deswegen wartest du erst am Ende darauf.
Die kürzeste Version ist system(). Die öffnet den Prozess und wartet auf dessen Beeindung, während das andere Programm läuft kann dein Programm also nichts machen.

Alle Funktionen sollten irgendwie auch unter Kylix zugänglich sein, aber frag mich nicht, in welchen Units (system() und popen()/pclose() sollten in libc.pas sein).
Die erste Variante ist natürlich am flexibelsten, weil sie einen echten Fork bildet und exec() das Image entsprechend ersetzt. Die letzten beiden Varianten erzeugen *beide* zunächst eine Shell (es wird /bin/sh verwendet), die das übergebene Kommando ausführen. Dadurch kann das Kommando zwar auch ein Shell-Internal sein, aber wenn du ungeprüft Benutzereingabe auf diese Art und Weise ausführst, reißt du Sicherheitslöcher auf. Zum Beispiel ersetzt die Shell den Asterisk (*) oder verlangt nach String-Escaping und Schutz von Leerzeichen. Wenn du also vom Benutzer ein Kommando eingeben lässt, ist es deine Aufgabe, dieses auf alle Eventualitäten zu überprüfen und entsprechend abzusichern. Die erste Variante ist zwar aufwändiger, dafür aber mit weniger Overhead verbunden und prinzipiell mit weniger Sichtheitslücken behaftet.