Category: UNIX

Die Aufgabe lautet die UTF-8 BOM (0xEFBBBF) mittels eines Hexeditors in ein simples Textfile einzufügen.
Getestet wurden auf Ubuntu 12.04 verschiedene Tools – hier das Ergebnis:

1. hte (Konsolenhexeditor mit ncurses)

Leider ist die Integration von ncurses in die Ubuntu Welt – genauer gesagt in ein Gnome Terminal – nicht prickeld. Wesentliche Kommandos die mit der ALT Taste gesteuert werden wurden anstatt in das ncurses Programm an das darüberliegende Terminal übertragen, so dass ich es nicht schaffen konnte in den Edit Mode zu kommen. Ansonsten ist die grafische Representation des Byte-Codes ansprechend.

2. vi (mittels xxd)

Falls man mit vi -b ein File im binären Modus öffnet, kann man mit folgender Sequenz
:%!xxd
..Manipulation des Files
:%!xxd -r
die Datei ändern. Das Hinzufügen oder Entfernen von Bytes gelang mir auf Anhieb nicht. Mein Fazit: Für schnelle Manipulationen ideal, aber nur dafür.

3. okteta

Der KDE Hexeditor läuft selbstverständlich auch auf dem Ubuntu Unity Desktop. Was die Optionen der grafischen Representation anbelangt das beste Programm. Im Detail offenbaren sich – wie so oft unter KDE Schwächen. Bei der Characterdarstellung der Bytes sollte man sich auf einen rein lokalen 8-Byte Zeichensatz beschränken anstatt dem User vorzugauckeln, dass ein Byte eines Umlautes unter UTF-8 einem Character entspricht (bei der Byte-Sequenz C3B6 ‚ö‘ wird schon alleine C3 unter UTF-8 als ‚ö‘ dargestellt, zumindest in der Decoding Tabelle). Auch die Layout-Voreinstellungen der GUI sind nicht optimal.

4. bless

Das Mono-basierte Programm hat leider die Systembedingten Abhängigkeiten von allerhand Mono-Libraries.
Ansonsten wirkt das Programm aber sehr aufgeräumt und stringent. Von der Bedienung her das einfachste Programm – allerdings kann es nach der Manipulation nicht auf das geöffnete File zurückschreiben. Wer das versucht, bekommt folgende kryptische Fehlermeldung.

Fazit: Je nach Geschmack eignet sich okteta oder bless am Besten für diese Aufgabe

Wenn sich ein File auf einem Linux System nicht mal mit Hilfe eines root-accounts löschen lässt, dann sollte man mal die sog. I-node flags (Extended Filesystem Attributes) genauer anschauen. Der Befehl dazu lautet

lsattr <FILE>

Falls in der Ausgabe der Character i vorkommt, dann ist das sog. FS_IMMUTABLE_FL flag gesetzt worden, welches eine Modifikation des i-Nodes gänzlich unterbindet (d.h. weder inhaltliche Veränderung noch eine Änderung von Metadaten ist erlaubt).
Ein Setzen des Flags mit

chattr +i <FILE>

erfordert die CAP_LINUX_IMMUTABLE capability. Programmatisch erfolgt dieselbe Operation mit ioctl

if (ioctl(fd,FS_IOC_GETFLAGS,&attributes)==-1) errExit("fetching attributes");
attributes |= FS_IMMUTABLE_FL;
if (ioctl(fd,FS_IOC_SETFLAGS,&attr) == -1) errExit("setting attributes");

Dieses i-node flag ist unter Linux seit Kernel 2.6.19 Filesystem-übergreifend implementiert. Es kann bspw. zum temporären Schutz von Dateien in Systemverzeichnissen genutzt werden, aber auch von Rootkits die Schadsoftware ins System eingeschleust haben.

Standardprozesse unter Linux werden nun schon seit Kernel 2.6.23 durch den Complete Fair Scheduler verarbeitet, der seinerzeit den O(1) scheduler mit seinen dynamschen Prioritäten beerbte.

In diesem Zusammenhang wurde aber nicht nur der O(1) scheduler durch einen anderen ersetzt. Es wurde vielmehr ein ganzes scheduler Framework erschaffen, bei dem von oben nach unten die scheduler Klassen mit Ihren jeweiligen schedulern abgearbeitet werden. Der simple Ansatz lautet, dass immer versucht wird denjeniegen Prozess zu finden, welcher in der höchstmöglichen Klasse lauffähig (runnable) ist.
Derzeit sieht die scheduler Klassenhierarchie folgendermaßen aus:

1. stop_sched_class
2. rt_sched_class
3. fair_sched_class
4. idle_sched_class

Die Hintergründe sind im aktualisierten Linux Realtime Dokument zusammengefasst.

Die Multipurpose Internet Mail Extensions sind entgegen ihrem Namen auch für die Identifizierung eines Dateityps auf Linux Desktops verantwortlich.

Eine gemeinsame Technik der freedesktop Organisation sorgt dafür, dass ein Verfahren dabei auf allen Desktops‘ – Gnome,KDE,Unity.. – gleichermassen funktioniert. Die gemeinnützige Organisation kümmert sich dabei vor allem um die Standardisierung und stellt teilweise sogar SW (software) bereit.
Eine Übersicht der MIME-Type Spezifikation findet sich hier, während der Ordner mit den letzten verfügbaren Änderungen sich hier befindet.

Wenn man einen oder mehrere neue MIME-Types (mit dazugehörigem Programm) einführen möchte, geht man am besten folgendermaßen vor:

1. Man sucht sich einen passenden Ablageordner – die auf dem System vorhandenen sind
   $XDG_DATA_DIRS/mime
$XDG_HOME_DIR/mime
   falls XDG_HOME_DIR nicht gesetzt ist, gilt
   ~/.local/share/mime
   Natürlich kann man bspw. XDG_DATA_DIRS auch erweitern um einen neuen Pfad einzuführen
2. Eigene MIME-Type Deklarierungen müssen innerhalb einer standardisierten XML-basierenden Datei im Ordner packages (unterhalb des Ordners mime) gespeichert werden, bspw
   ~/.local/share/mime/packages/myType.xml
   Eine xml Datei kann dabei auch mehrere MIME-Types definieren. Der genaue Vorgang erklärt eine hervorragende Tutorialseite auf freedesktop:
   Tutorial: adding MIME information to the database
3. Die sog. MIME-Type database muss aktualisiert werden. Dazu gibt es ein Skript welches die ganzen im Punkt 1. erwähnten Verzeichnisse durchscannt und dort jeweils dezentral binär aufgebaute Hilfsdateien anlegt. Das shell script welches natürlich mit Administrationsrechten ausgeführt werden muss, lautet
   update-mime-database
4. Die Verknüpfung eines MIME-Types mit einem Programm ist nicht Sache der MIME-Type Definition. Stattdessen legen die Programmbeschreibungsdateien, die sog. desktop-Dateien, offen welche MIME-Types sie bearbeiten. Diese Dateien mit der Endungs .desktop, liegen in
   XDG_DATA_DIRS/application
XDG_HOME_DIR/application
   mit denselben Ergänzungen wie im Punkt 1.
   Die freedesktop Spezifikation findet man auf folgender Seite. Ein anschauliches Beispiel findet sich hier.
5. Nachdem man die MIME-Types und Anwendungen die bestimmte MIME-Types bearbeiten können festgelegt hat bleibt noch folgende Frage zu klären: Welche Anwendung ist die bevorzugte Anwendung eines MIME-Types, bspw. image/png ?
   Dort hat jeder Desktop (bspw. KDE) seine Voreinstellungen in der generierten mime.cache Datei (siehe Punkt 3. – Hilfsdateien) getroffen. Diese Entscheidungen können aber ergänzt oder geändert werden.
   Dazu muss man die Datei
   mimeapps.list
   unterhalb von
   XDG_DATA_DIRS/application
XDG_HOME_DIR/application
   ändern. Wie genau erklärt die Spezifikation auf freedesktop an dieser Stelle.
   Neben der Angabe einer bevorzugten Anwendung für einen MIME-Type in der Sektion
   [Default Associations]
   gibt es auch noch die Möglichkeit zusätzliche Assoziationen zu kreieren oder zu vorhandene zu löschen.

6. Am Ende bleibt noch die Frage wie man an diese MIME-Type Informationen gelangt? Sicher, haben die grossen Desktops Routinen dafür entwickelt die den Spezifikationen von freedesktop genügen, aber wie kommt man als ISV (Independent Software Vendor) an diese Informationen.
   Vorab – eine API gibt es nicht – unter keiner Sprache. Was es gibt sind Skripte allen voran
   xdg-mime
   des Portland SW Paketes von freedesktop (der SW Part von freedesktop, siehe Einleitung). Unter Ubuntu/Debian gibt es auch noch das Perl-Skript
   mimetype
   mit welchem man wesentlich mehr Informationen abgreifen kann.
   Zu diesem Thema möchte ich noch auf 2 nützliche Links verweisen
   http://wiki.ubuntuusers.de/MIME-Typ
   http://aksubuntu.com/questions/279899

Abschliessend lässt sich sagen, dass die MIME-Type Informationen unter Linux ausgereift und ausreichend ist. Was verbesserungsbedürftig ist, und leider gerade dahindarbt, ist die SW-Unterstützung, v.a. eine C/C++ API seitens freedesktop.org wäre wünschenswert. Dies soll aber nicht darüberhinwegtäuschen, dass die Zusammenarbeit der Linux Desktops gut funktioniert.

Eine Überraschung erlebte ich beim Bauen einfacher Demonstrationsprogramme unter Ubuntu 12.04. Folgende Anweisung:

gcc -lpthread -o pthread_demo pthread_demo.c

erzeugte beim Linkvorgang mehrere unresolved symbols bzgl. pthread Methoden. Tatsächlich wurde aber mit gleicher Anweisung das Programm zu den Anfangszeiten von Ubuntu 12.04 gebaut. Eine Umstellung des Linker Programms ld bzw. der Aufruf desjeniegen durch gcc dürfte daran schuld sein. In ld Version 2.20 führt der Linker-Flag

--as-needed

dazu, dass Bibliotheken nur noch gelinkt werden wenn diese undefined Symbols im Objekt File oder einer zuvor gelinkten Bibliothek auflösen kann. Daher muß von nun an das Objekt File vor den benötigten Bibliotheken im gcc Aufruf stehen.

gcc -o pthread_demo pthread_demo.c -lpthread

Alternativ könnte man das alte Verhalten mit folgendem Linker-Flag wiederherstellen

gcc -Wl,--no-as-needed -lpthread -o pthread_demo pthread_demo.c

Beim Standarddateimanager von Ubuntu 12.04 Nautilus kann man in der Seitenleiste bekanntlich Lesezeichen (bookmarks) anlegen, deren Name und Zielverweis wählbar ist.

Voreingestellt sind unter der Rubrik Rechner bereits ein paar Ordner, bspw. Dokumente, Bilder, Musik, Videos. Das Zielverzeichnis dieser Einträge lässt sich in Nautilus selber nicht ändern.
Die Zielverzeichnisse holt sich Nautilus – wie auch andere Programme – vom Desktop-übergreifenden Projekt freedesktop.org, welches die Einträge in folgender Datei ablegt.

$(XDG_CONFIG_HOME)/user-dirs.dirs

also im Normalfall

~/.config/user-dirs.dirs

Dort ändert man bspw. das Verzeichnis für XDG_DOWNLOAD_DIR um das Zielverzeichnis für den Download-Ordner zu ändern.