Schau dir mal die Doku zu NSTask an.

ohne garantie:

Es geht auch mit oder popen (3):

The popen() function ``opens'' a process by creating a bidirectional pipe
forking, and invoking the shell.

Gruss

Below

Uuuh - Leute! was macht ihr denn da?!

Startet Ihr Kommandozeilentools um eine popelige crc32 zu berechnen?! Und blast danach alles über eine Pipe nur um an das Ergenis zu kommen?! Wer macht denn so "ugly things" ?

Ich meine - Kommandozeilentools aus einem Programm starten... Leute, Leute... Was ist denn das für ein Programmierstil?

Also ich persönlich finde das sehr, sehr unschön. Derweil liegt das Gute doch so nah!

Verwendet doch die crc32() Routine der zlib!

Ausserdem geht das dann mit zwei popeligen Zeilen und ich behaupte mal so aus dem Stegreif es ist um einiger performanter als Shell-Kommandus zu feuern...

Das Schöne an dieser Lösung ist dessen Würze in der Kürze und auch, dass man den Polynom vorgeben kann! Ausserdem bietet der crc32 der zlib den grossen Vorteil, dass man direkt CRC aus Speicherblöcken errechnen lassen kann



...und nicht vergessen, die zlib hinzuzulinken! (-lz) !

Happy Codin'

- James -

Also, mal davon abgesehen, dass es mit der Lib einfacher ist: Der Start von cl-Tools aus einer GUI-App ist überhaupt nicht unschön, sondern sogar unter Umständen extrem guter Programmierstil.

Apple macht es übrigens zahlreich so.

Hier und da mach ich das auch, aber nur wenn es nicht anders möglich ist. Sobald ne Lib vorhanden ist, wird diese eingebunden. und die zlib ist wirklich ziemlich easy.

@Tom
und nur weil Apple es macht, heißt es nicht das es gut ist;-)

Aber es ist nett so etwas wie NSTask in der Hinterhand zu haben. Das Vereinfach viele Dinge ungeheim.

Sven

Original von MetalSnake
@James
Von der zlib habe ich noch nichts gehört und finde auch nichts darüber in den Dokus die ich hier habe.
Und uin32_t kenne ich auch nicht, steht auch nirgends in meinen Dokus

Habe zwar die man page zu zlib und die Webseite dazu gefunden aber das hilft mir leider auch nicht so recht

zlib ist die Bibliothek mit der die Kompression von gzip gemacht wird. Und gzip ist so ziemlich der bekannteste Packer in der Unix Welt.
Wenn Du wirklich nur die crc32 Funktion brauchst und keine sonstigen "Programme", dann verwende die zlib. Kannst Du bei jedem Mac OSX vorraussetzen.

uint32_t ist nur ein typedef auf "unsigned int". Mach Dir deswegen keine Gedanken, Du koenntest genauso "unsigned int" schreiben. Es gibt noch mehr solcher typedefs, schau Beispielsweise man in "/usr/include/sys/types.h" rein.

Manfred

Deshalb schrieb ich auch "übrigens".

Original von MetalSnake
gzip und zip kompression und dekompression brauche ich auch, zip scheint die zlib aber nicht zu können wenn ich die man richtig interpretiere, ist aber auch nicht so wichtig wie gzip.

in der types.h Datei steht:
typedef u_int32_t fixpt_t; /* fixed point number */

wozu sollen die typedef denn gut sein?

Wo gibts denn eine Doku wie ich solche libs wie zlib einbaue?

Zum Teil macht man die typedefs um kompatibel mit anderen Unix Derivaten zu sein, weil dort der Datentyp eine andere Bezeichnung hat.
Zum Teil auch ums einfach abzukuerzen. Und zum Teil um nicht so abhaengig von Veraenderungen und Architekturen zu sein.
uint32 hat immer 32 bit. Wenn du statt dessen unsigned int nehmen wuerdest, koennte es sein, dass auf einem anderen System unsigned int 64 bit oder vielleicht nur 16 bit hat.

Die zlib oder generell Bibliotheken bindest Du ganz einfach ein. James hats eigentlich schon gesagt, ich machs vielleicht noch etwas ausfuehrlicher.

Im Prinzip sind es drei Schritte:
1. die Funktionsprototypen der Bibliothek muessen in deinem Quellcode bekannt sein, damit Du sie verwendet kannst. Das gescheiht durch Einbinden der Header-Dateien, hier zlib.h (liegt in /usr/include/")
2. verwenden der Funktionalitaet der Bibliothek indem Du die Funktionen benutzt. Hier als Beispiel die crc32 Funktion. Siehe Posting von James.
3. dem Linker sagen, dass er doch bitte zusaetzlich gegen die jeweilige Bibliothek linken soll um die Funktionen, die Du benutzt hast aufzuloesen. Als Beispiel, wenn Du willst, ist die Header-Datei das Inhaltverzeichnis und das Glossar der Bibliothek wo nur drin steht, welche Funktionen es gibt. Der eigentliche Inhalt steht als compilierter (binaer) code in der Bibliothek selbst.

Das Einbinden der Header-Datei alleine reicht also nicht. Der Compiler wird den Code zwar compilieren, weil der den Prototypen der Funktion aufloesen kann (Header-Datei) aber der Funktioinsaufruf wird fehlschlagen, weil der Code, der dahintersteckt nicht verfuegbar ist.
Dazu muss dem linker gesagt werden, loese die Funktionen der Bibliothek auf.
Das macht man mit einem zusaetzlichen Aufruf-Parameter des Compilers bzw. Linkers. Bibliotheken, die in dem Standard Bibliotheken-Verzeichnis liegen (/usr/lib/) heissen normalerweile immer lib<irgendwas>.dylib. Dann reicht das hier: "-lz".
Den Parameter kannst Du in Xcode eingeben, indem Du zu den "Build" Einstellungen des Targets gehst. Dort gibt es "Other linker flags" oder so. Dort traegst Du "-lz" ein. Und schon ist der Fall erledigt. Beim builden wird nun automatisch gegen die libz gelinkt.

Im Prinzip funktioniert das mit der Bibliothek so: Beim Ausfuehren Deines Programms ist bekannt, welche Bibliotheken es braucht (hier z.B. zlib), die wird dann vom System an eine bestimmte Adresse in den Speicher geladen und bei einem Aufruf einer Funktion der Bibliothekn aus Deinem Programm, wird der vom System geladene Code ausgefuehrt. Dein Funktionsaufruf ist also in Wirklichkeit ein Sprung an eine andere Speicherstelle, naemlich die, in die der Code der Bibliothek geladen wurde.

Manfred

man zlib

Dort sind auch wieder Links auf FAQ etc Seiten.

Sven

Original von Tom9811
Also, mal davon abgesehen, dass es mit der Lib einfacher ist: Der Start von cl-Tools aus einer GUI-App ist überhaupt nicht unschön, sondern sogar unter Umständen extrem guter Programmierstil.

Hi Tom,

naja über Geschmack lässt sich (zum Glück) ja streiten...

Und "unter Umständen" gibt es in diesem Kontext meiner Meinung halt nicht. Denn mit einer relativ bezogenen Formulierung wie sie "unter Umständen" darstellt, kann man freilich jede strikte Forderung verwässern.

Der Satz "Ein verschmutztes Klo ist unter Umständen auch hygienisch schliest sich ja auch aus"! - ... zumindest für mich als hygiene liebender Mensch.

Ich bin der Meinung, dass jeder sich eher früher als später selbst gewisse "Coding Rules" definieren & angewöhnen sollte. Und dazu gehört meines Erachtens auch (s)eine Definition für einen guten Prog.-Stil.

Aber all das ist eben, wie schon gesagt nur meine bescheidene Meinung...

Vielleicht sollte ich Kay mal fragen, ob er noch ein Board ala "esotherische Betrachtungen zur Softwarentwicklung" aufmachen will, das wäre dann doch eine lustiges Thema zur Einführung - ... wie "Marcel Reich Ranitzkys literarisches Quartett"... *lol*

Apple macht es übrigens zahlreich so.

So, so und weil Apple das auch so macht, impliziert das dann einen guten Programmierstil? Ah ja...

..
gzip und zip kompression und dekompression brauche ich auch, zip scheint die zlib aber nicht zu können wenn ich die man richtig interpretiere, ist aber auch nicht so wichtig wie gzip.

Obacht Metalsnake!

zip ist ein Archivierungsformat welches aber nur den selben Kompressionsalgorithmus den auch die zlib anbietet, verwendet!

Denn ein Archivierungsformat ist eben weit mehr als nur ein Kompressor - es enthält Verwaltung für Filehirarchien und deren Attribute etc. ...

Die Unterschiede stehen auch in einem Artikel bei Wikipedia.
Hier findest Du auch einige Links, die auf weitere Details der zlib verweisen.

Die zlib ist zum Handhaben von zip-Archiven nicht ausreichend. Dazu muss man sich erst gemäss der ZIP-Spec die einzelnen Datenblöcke (Files) vorknöpfen und dann der zlib zum Entkomprimieren geben. Also die ZLIB dient lediglich der Kompression/Dekompression von streams - wie auch immer die geartet sind (filebasiert, memoryblocks, eigens abstrahierte Datenmodelle ...).

Du kannst mit der zlib eigene Datenblöcke schön komprimieren und dekomprimieren wie Du aber diese organisierst, bleibt Dir überlassen. zip ist so gesehen auch nur eine Art der Datenorganisation. (siehe auch die Anatomie eines ZIP-Archives)

Die Anwendung der zlib zur Kompression / Dekompression von Daten ist nicht unbedingt trivial, denn sämtliche I/O Operationen sind streambasiert. Dieses Konzept gilt es erst mal zu verstehen.

Wenn Es Dich/Euch interessiert, kann ich Dir gerne einen Code-Snippet zukommen lassen, der zeigt, wie man den Inhalt eines NSData Objektes mittels der zlib komprimiert und auch wieder ein Solches restauriert...

...oder sollte ich besser einen kleines Beispielprojekt in die Database hochladen?

Schöne Grüsse

- James -

Du hast das ja allgemein ausgedrückt, nicht ich.

Ich meine - Kommandozeilentools aus einem Programm starten... Leute, Leute... Was ist denn das für ein Programmierstil?

Und ich meine auch nicht irgendwleche absurden Randbedingungen, sondern jeden Client der durchläuft und seltene Bedienung benötigt, also etwa alle Datenbanksysteme, Dämonen usw. Ebenso verhält es sich bei Standard-Toools, die auf cli vorhanden sein müssen und denen man zusätzlich eine GUI verpassen will.

Hier ist es guter Stil, eine Trennung von Front-End und Back-End vorzunehmen, kein schlechter Stil.

Und ehrlich geasagt, finde ich auch, dass man darüber nicht streiten kann. Die obige Aussage ist ganz sicher falsch.

Original von Tom9811
Du hast das ja allgemein ausgedrückt, nicht ich.

Ich meine - Kommandozeilentools aus einem Programm starten... Leute, Leute... Was ist denn das für ein Programmierstil?

Übrigens - Du hast den Smilie, den ich übrigens ganz bewusst in oben zitierten Satz einfügte im Qute vergessen. - Ich erlaube ihn deshalb in nochmals dort einzufügen, denn dieses Emoticon zeigt, dass ich damit niemand angreifen will, sondern diese These durchaus im Spass äußerte. Und wer weiss damit auch zum Nachdenken anregen will...

...Und ehrlich gesagt, finde ich auch, dass man darüber nicht streiten kann. Die obige Aussage ist ganz sicher falsch.

Wie gesagt Tom,

das ist Deine Meinung - Ich vertrete eben eine Andere. Und das ist doch auch erfrischend, nicht wahr?

Schau, für mich ist und bleibt es eben ein "schlechter Programmierstil" Kommandozeilentools aus Hochsprachen heraus aufzurufen.

Und ja ich oute mich - ich tat es auch schon, bin aber mit der Lösung nicht sonderlich zufrieden und diese Punkte stehen dann zur Bereinigung ganz oben auf meiner ToDo-List.

Und dieses mir selbst gesetzte Paradigma wird auch nicht durch eine These, dass es durch dieTrennung zwischen einer GUI und der davon unabhängigen Programmlogik als das Mittel der Wahl erlaubt sei für mich legitimiert.

Abschließend bin ich der Meinung, daß Aussagen in diesem Kontext weder als wahr noch falsch zu bewerten sind. Es sind schlichterdings nur die Meinungen eines jeden Einzelnen, der es eben handhaben möge, wie er will.

In diesem Sinne - Happy codin'

- James -

Übrigens - Du hast den Smilie, den ich übrigens ganz bewusst in oben zitierten Satz einfügte im Qute vergessen. - Ich erlaube ihn deshalb in nochmals dort einzufügen, denn dieses Emoticon zeigt, dass ich damit niemand angreifen will, sondern diese These durchaus im Spass äußerte. Und wer weiss damit auch zum Nachdenken anregen will...

Sorry dafür, ist beim c&p wohl verlorengegangen.

Wenn sie zum Nachdenken anregen soll, so habe ich ja gerade deshalb geantwortet.