000
22.10.2004, 11:13 Uhr
virtual
Sexiest Bit alive
(Operator)
|
Warum system schlecht ist
(Bitte bei Bedarf ergänzen)
Im folgenden möchte ich einige Gründe vorstellen, die gegen die Verwendung von system sprechen. Dafür ist es notwendig, sich klar zumachen, was system eigentlich macht. Die landläufige Meinung ist, daß folgender Code
das Programm pause ausführt. Das ist schlicht und ergreifend falsch: jeder, der den Inhalt seiner festplatte kennt, wird feststellen, daß dieses Programm garnicht existiert. Abgesehen davon, das PAUSE nur etwas ist, was unter Windows - wie auch immer - funktioniert, wird vergeblich nach ein pause.exe, pause.com oder pause.bat auf seiner Windowsplatte suchen.
Warum wartet aber das eigene Programm dennoch auf einen Tastendruck? - Nun: system führt nicht das Programm pause aus, sondern dem Kommandozeileninterpreter des jeweilen Betriebssystems und übergibt den String pause diesem Kommandozeileninterpreter.
Unter Windows ist der Kommandozeileninterpreter das Programm, welches in der Environmentvariable COMPSPEC definiert ist; unter UNIX entsprechend das Programm, welches mit der Environmentvariable SHELL definiert ist.
1. Nachteil
Damit wären wir schon mal beim ersten Nachteil der Funktion system: Man hat eigentlich keine Garantie, was ausgeführt wird, weil der Anwender die Umgebungsvariable ja beliebig davor umgesetzt haben könnte. Daß dies ein massives Sicherheitsrisiko ist, dürfte klar sein.
Desweiteren geht system hin und führt nun also den Kommandozeileninterpreter mit dem Kommando aus, welches wir angegeben haben, währenddessen ruht die Ausführung unseres eigenen Programms:
2. Nachteil
Man nimmt also einen kompletten Kontrolverlust des eigenen Programms in kauf, vertraut daß das andere Programm schon wohl das machen wird, was wir vermuten; daß es derart fehlerfrei ist, daß es garantiert zurückkommt. Unter Linux kann ich diese Haltung zwar nachvollziehen: ist ja bekanntlich total bugfrei, stürzt niemals ab und alle Programme sind von unfehlbaren Programmierern geschrieben ( ), aber unter Windows ist eine solche Annahme mehr als gewagt.
"Ja, ja", mag der geneigte Leser denken, "unser virtual war schon immer paranoid". Dem kann ich nur entgegenen, daß mir das schon oft dem Kopf gerettet hat...  Aber nichts desto trotz, nehmen wir an, daß alle Programme auf dem Rechner total fehlerfrei wären (was ja schon an sich eine ziemliche Utopie ist):
3. Nachteil
Es kann sein, daß das Programm garnicht da ist. Das eingangs erwähnte pause gibts zB nur bei Windowsstandardinstallationen; unter UNIX erstmal nicht. Auch so beliebte Tricks unter Windows eine "bmp" Datei aufzurufen fallen in die gleiche Kategorie: niemand garantiert, daß die Verknüpfung für eine "bmp" Datei so gesetzt ist, wie man auf dem Entwicklungs oder Testrechner eingesetzt hat. Siehe auch Nachteil 1. Generell begibt man sich mit system nicht nur in die Plattformabhängigkeit, sondern sogar noch viel weiter in die Installationsabhängigkeit...
Speziell unter richtigen Betriebssystemen (Da fällt mir eigentlich nur BSD, Linux, UNIX et.al. ein) gibt es häufig "restricted environments", also Umgebungen, in dem ein User nur ein begrenztes Maß an Resourcen zur Verfügung hat. Beliebt ist zB die Anzahl der Prozesse zu begrenzen: versucht ein Programm einen weiteren zu starten, wird dies kurzerhand nicht erlaubt:
4. Nachteil
system birgt die Gefahr, daß die Operation nicht ausgeführt wird, selbst wenn die og Nachteile nicht zählen: irgendein quota oder eine sonstige Restriction wirds schon im unangenehmsten Augenblick richten, daß das Programm, welches system starten soll, überhaupt nicht losgeht.
"Alles Mumpitz", sagt da jemand, "ich will doch nur den Bildschirm löschen, bzw. auf eine Taste warten!" - Das ist nicht kritisch. Mein gegenargument:
5. Nachteil
Du willst den Bildschirm löschen? - Warum tust du es dann nicht einfach? - Wenn Du system startest, startest Du mindestens einen, vielleicht sogar zwei zusätzliche Programme, nimmst die og Nachteile in Kauf, aber bist Dir immer noch nicht sicher, ob der Bildschirm wirklich leer ist. Jedes Betriebssystem hat API Funktionen, um den Bildschirm zu löschen. Die sind genauso unportabel, wie das, was man system als Parameter mitgibt - nur eben schnell, sicher und risikofrei!. Meistens genügt übrigens auch eine einfach printf Anweisung, um den Bildschirm zu löschen...
Du willst auf einen Tastendruck warten? - Warum tust du es nicht einfach? - Argumentation wie oben...
Fazit
1. Für Trivialaufgaben verbietet sich system völlig, weil das Betriebssystem trivialaufgaben besser lösen kann, als zwei Prozesse starten und hoffen, daß das korrekte passiert.
2. Für komplexere Aufgaben verbietet sich system völlig, weil man keine Kontrolle mehr über das hat, was passiert.
3. Für portable Programm verbietet sich system völlig, weil system nicht portabel ist.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
Dieser Post wurde am 22.10.2004 um 13:11 Uhr von Pablo editiert. |
