UNIXwork

Für alle Benutzer von NEdit, oder besser XNEdit, hier ein kleiner Tipp, wie man sein Leben im Umgang mit XML vereinfachen kann. Maschinell erstellte XML-Dateien zu bearbeiten kann manchmal ziemlich nerven, nämlich wenn diese nicht für den menschlichen Betrachter formatiert sind. Mit dem Tool xmllint, welches Teil von libxml2 ist, lässt sich dieses Problem lösen:

xmllint --format file.xml > formatted.xml

Die Ausgabe hiervon ist ein schön formatiertes XML-Dokument mit eingerückten Tags.

Da man natürlich nicht ständig irgendwelche Kommandos in der Shell ausführen möchte, bevor man eine Datei öffnet, empfiehlt es sich, xmllint in XNEdit zu integrieren. Hierfür müssen wir dem Shell-Menü einen neuen Befehl hinzufügen.

Die Einstellungen dafür öffnet man über Preferences → Default Settings → Customize Menus → Shell Menu...

Dort wählen wir zuerst oben links New und geben bei Menu Entry einen passenden Namen für den Menüeintrag ein.

Die Einstellungen, die wir dann noch benötigen, sind:

Command Input: document

Command Output: same document

Output replaces input

Der Befehl, der ausgeführt werden soll ist:

xmllint --format -

Ein Klick noch auf OK und der neue Menüeintrag steht im Shell-Menü zur Verfügung. Danach kann nach dem Öffnen einer XML-Datei über das Shell-Menü unser XML-Formatierungsbefehl ausgeführt werden.

Um X11-Anwendungen unter Windows auszuführen, benötigt man einen X-Server. Empfehlenswert ist da VcXsrv. Damit ist es problemlos möglich, Remote-X11-Anwendungen innerhalb von ssh-Sitzungen mit Putty auszuführen. Ebenso eignet sich VcXsrv für den Fall, dass man mittels WSL grafische Anwendungen ausführen möchte.

VcXsrv kann die X-Clients als einzelne separate Fenster in Windows anzeigen, aber auch im Vollbildmodus betrieben werden, was das Ausführen einer kompletten X11-Desktop-Sitzung möglich macht.

Copy & Paste funktioniert und auch bei der Texteingabe mit Umlauten sind mir keine Probleme aufgefallen. Das ganze macht für mich einen ganz brauchbaren Eindruck.

Mein bevorzugtes Tool, um z.B. aus PDFs Seiten zu extrahieren oder Dokumente zusammenzufügen, war mal pdftk, was allerdings nicht mehr weiterentwickelt wird und da es auch auf gcj basiert, der auch Geschichte ist, kriegt man es auch nicht mehr wirklich zum laufen. Als Alternative habe ich stapler entdeckt, was ähnlich leicht zu benutzen ist. Das Tool gibts auch im Fedora-Repo, dort heißt es allerdings pdf-stapler und wird auch über diesen Namen aufgerufen. Bei Ubuntu gibts das Programm hingegen nicht im Repository.

Hier mal ein paar Beispiele:

Seiten extrahieren

stapler sel doc.pdf 1 out.pdf
stapler sel doc.pdf 4-6 out.pdf

Reihenfolge von Seiten umkehren

stapler sel doc.pdf 3-1 out.pdf

Seiten drehen

stapler sel doc.pdf 1D out.pdf
stapler sel doc.pdf 1L out.pdf
stapler sel doc.pdf 1R out.pdf

D steht für Down, L für Left und R für Right.

Dokumente zusammenfügen

stapler sel file1.pdf file2.pdf out.pdf

Es können nach dem Dateinamen auch Selektierungsanweisungen (siehe oben) angegeben werden:

stapler sel file1.pdf 1-2 file2.pdf 6-9 out.pdf

Dokument splitten

stapler split doc.pdf

Ich hatte mal eine Anleitung dazu geschrieben, wie mittels fork und exec Kind-Prozesse erstellt und Programme ausgeführt werden. In diesem Artikel möchte ich die Funktion posix_spawn vorstellen, die im Prinzip das gleiche kann und dabei ein paar Vorteile hat.

In Unix werden traditionell Programme ausgeführt, in dem der aktuelle Prozess geforked, also dupliziert, wird und im neuen Kind-Prozess wird ein anderes Programm-Image mittels exec geladen.

Das Problem an der Sache ist, dass fork mehr oder weniger Overhead haben kann, je nach Betriebsystem. Linux ist da recht effizient, es werden aber immer noch die Page Tables des Parent kopiert. Dazu kommt, dass es auch etwas umständlicher zu programmieren ist, als nur eine einzige Funktion aufzurufen.

Daher wurde irgendwann die Funktion posix_spawn eingeführt:

int posix_spawn(pid_t *pid, const char *path,
	   const posix_spawn_file_actions_t *file_actions,
	   const posix_spawnattr_t *attrp,
	   char *const argv[], char *const envp[]);

Um z.B. das Programm /bin/echo in einem separaten Prozess auszuführen, reicht folgender Code:

char *args[3];
args[0] = "echo";
args[1] = "Hello World";
args[2] = NULL;

pid_t pid; // child pid
posix_spawn(&pid, "/bin/echo", NULL, NULL, args, NULL);

Das ist ein sehr einfaches Beispiel. Was man eigentlich noch bräuchte, ist eine Möglichkeit, die Filedescriptoren für stdin, stdout und stderr zu modifizieren. Hierfür gibt es den Parameter file_action. Um den zu verstehen, sollte man sich noch mal anschauen, wie Programme mittels fork und exec ausgeführt werden, daher noch mal eine kleine Zusammenfassung meines Artikels dazu.

Stdin, stdout und stderr sind Filedescriptoren, die immer die Nummern 0, 1 und 2 haben. Mit der Funktion dup2 können wir einen Filedescriptor duplizieren und der Kopie eine exakte Nummer zuweisen. Was man also machen muss ist, vor dem Erstellen des neuen Prozesses erstmal neue Filedescriptoren für stdin/stdout/stderr zu erstellen (z.B. mit pipe oder open) und nach dem Erstellen des Kind-Prozesses aber noch vor exec werden mittels dup2 die Filedescriptoren auf die Positionen 0, 1 und 2 gelegt.

Der file_actions Parameter bei posix_spawn ist genau dafür gedacht. Diesem können Aktionen wie dup2 oder auch close und open zugeordnet werden, die dann nach dem Erstellen des Kind-Prozesses verarbeitet werden.

Zuerst muss file_actions hierfür initialisiert werden:

posix_spawn_file_actions_t actions;
posix_spawn_file_actions_init(&actions);

Danach können Actions zugewiesen werden:

// stderr im Kind-Prozess schließen
posix_spawn_file_actions_addclose(&actions, 2);

// stdout in die Datei out.txt umleiten
posix_spawn_file_actions_addopen(&actions, 1, "out.txt", O_CREAT|O_WRONLY, 0644);

Nach dem Ausführen von posix_spawn sollte der Speicher wieder freigegeben werden:

posix_spawn_file_actions_destroy(&actions);

Ich habe auch ein ausführliches Beispiel geschrieben, in dem die Ausgabe in eine Pipe mit Hilfe von posix_spawn_file_actions_adddup2 umgeleitet wird, die dann im Parent ausgelesen wird.

Ich war etwas überrascht, als FreeBSD meine Netzwerkkarte von Mellanox nicht erkannt hat. Die Mellanox ConnectX-2 ist vielleicht eine der verbreitetsten 10GbE-Netzwerkkarten.

FreeBSD unterstützt die natürlich auch, allerdings muss man da wieder manuell eingreifen. Es fehlt nur eine Zeile in der Datei /boot/loader.conf.

mlx4en_load="YES"

Nach einem Reboot wird der Treiber für die Netzwerkkarte geladen. Danach kann man sein Netzwerkinterface konfigurieren. In meinem Fall wollte ich DHCP und dafür waren folgende zusätzlichen Zeilen in /etc/rc.conf nötig:

ifconfig_mlxen0="DHCP"
ifconfig_mlxen0_ipv6="inet 6 accept_rtadv"

Danach noch folgenden Befehl ausführen:

service dhclient start mlxen0

Und das Netzwerk dürfte funktionieren.