In diesem Beitrag zeige ich euch, wie ihr ein solches Skript erstellt. Als Beispiel möchte ich demonstrieren, wie man Bilder in das WebP-Format umwandelt, ohne eine Bildbearbeitungssoftware öffnen zu müssen. Dazu verwende ich cwebp, ein leistungsstarkes Tool zur Konvertierung von Bildern in das WebP-Format, sowie Zenity um eine grafische Benutzeroberfläche für die Eingabe von Bildgrößen bereitzustellen.

Warum WebP?

WebP ist ein modernes Bildformat, das eine bessere Komprimierung als JPG oder PNG ermöglicht, ohne die Bildqualität merklich zu beeinträchtigen. Es ist besonders für Webentwickler und Blogger von Vorteil, da es die Ladezeiten von Webseiten reduziert und somit die Performance verbessert.

Vorbereitung: Benötigte Pakete installieren

Bevor ihr mit dem Skript beginnt, stellt sicher, dass die erforderlichen Programme installiert sind. Falls nicht, könnt ihr diese unter Debian-basierten Distributionen wie Ubuntu oder TUXEDO OS mit dem folgenden Befehl installieren:

### Unter Arch Linux, Manjaro und Co.
$ sudo pacman -S libwebp zenity
### Unter Ubuntu, Debian und Co.
$ sudo apt install webp zenity

Erstellung des Skripts zur WebP-Konvertierung

Legt ein neues Skript im Nautilus-Skripte-Ordner an:

$ mkdir -p ~/.local/share/nautilus/scripts
$ gedit ~/.local/share/nautilus/scripts/ConvertToWebP

Fügt nun den folgenden Code in die Datei ein und speichert sie:

#!/bin/bash

# Überprüfen, ob cwebp und zenity installiert sind
if ! command -v cwebp &> /dev/null; then
    zenity --error --text="cwebp ist nicht installiert."
    exit 1
fi

# Benutzer nach Breite und Höhe fragen
input=$(zenity --forms --title="Bildkonvertierung nach WebP" \
    --text="Gebt die gewünschte Breite und Höhe ein (0 für Originalgröße):" \
    --add-entry="Breite" \
    --add-entry="Höhe")

# Falls der Benutzer abbricht, das Skript beenden
if [ -z "$input" ]; then
    exit 1
fi

width=$(echo "$input" | cut -d '|' -f1)
height=$(echo "$input" | cut -d '|' -f2)

# Falls keine Werte eingegeben wurden, Standardwerte setzen
width=${width:-0}
height=${height:-0}

# Alle ausgewählten Dateien verarbeiten
for file in "$@"; do
    if [ -f "$file" ]; then
        output="${file%.*}.webp"
        
        if [[ "$width" -eq 0 && "$height" -eq 0 ]]; then
            # Keine Skalierung, direkt konvertieren
            cwebp "$file" -o "${file%.*}.webp" >/dev/null 2>&1
        else
            cwebp -resize "$width" "$height" "$file" -o "${file%.*}.webp" >/dev/null 2>&1
        fi
    fi
done

Rechte setzen

Damit das Skript ausgeführt werden kann, muss es als ausführbar markiert werden. Das geht mit:

$ chmod +x ~/.local/share/nautilus/scripts/ConvertToWebP

Skript in Nautilus einbinden

Nachdem das Skript erstellt wurde, ist es direkt über den Dateimanager Nautilus verfügbar. Wählt eine oder mehrere Bilder aus, klickt mit der rechten Maustaste darauf, navigiert zu Skripte und wählt ConvertToWebP aus.

Das Skript konvertiert nun alle markierten Bilddateien in gängigen Formaten in das WebP-Format und reduziert deren Größe, während es das Seitenverhältnis beibehält. Falls cwebp nicht installiert ist, wird eine Fehlermeldung ausgegeben. Alternativ könnt ihr die gewünschten Zielgrößen für Breite und Höhe in Pixeln angeben.

Gerade ganz frisch veröffentlicht wurde die Erweiterung Copy File Contents. Sie ermöglicht es, den Inhalt einer Datei direkt aus dem Dateimanager in die Zwischenablage des Systems zu kopieren, ohne die Datei erst einmal umständlich in einem Editor oder im Vorschau-Modus (über die Leertaste) öffnen zu müssen. Besonders für Nutzer, die regelmäßig mit Textdateien arbeiten, ist diese Erweiterung daher eine echte Erleichterung.

Voraussetzungen

Bevor ihr die Erweiterung installieren könnt, müsst ihr sicherstellen, dass das Paket nautilus-python auf eurem System vorhanden ist. Dieses Paket ist in den meisten Software-Repositories der gängigen Distributionen verfügbar. Die Installation erfolgt abhängig von der verwendeten Linux-Distribution folgendermaßen:

$ sudo apt install nautilus-python   # Ubuntu, Debian und Co.
$ sudo dnf install nautilus-python   # Fedora
$ sudo pacman -S python-nautilus     # Arch Linux und Co.

Installation der Erweiterung

Die Erweiterung selbst ist noch nicht in den Paketquellen verfügbar, kann aber bequem über ein Makefile oder auch manuell installiert werden. Zuerst klonst ihr das Repository und wechselt dann in das entsprechende Verzeichnis:

$ git clone https://github.com/EuCaue/nautilus-extension-copy-file-contents.git
$ cd nautilus-extension-copy-file-contents

Installation über Makefile

Mit folgendem Befehl installiert ihr die Erweiterung:

$ make install

Dabei wird die Erweiterung nach ~/.local in das Home-Verzeichnis installiert, ohne dass ihr administrative Rechte benötigt.

Manuelle Installation

Alternativ könnt ihr die Erweiterung manuell installieren. Kopiert das dazu einfach das Python-Skript in den Nautilus-Erweiterungsordner:

$ mkdir -p ~/.local/share/nautilus-python/extensions/
$ cp ./src/nautilus_copy_file_contents.py ~/.local/share/nautilus-python/extensions/

Nach der Installation müsst ihr generell lNautilus neu starten. Dies kannst du über folgenden Befehl im Terminal erledigen. Einen „richtigen“ Eintrag in den Menüs des Dateimanagers gibt es nicht.

$ nautilus -q

Deinstallation der Erweiterung

Wenn ihr die Erweiterung deinstallieren möchtet, stehen euch ebenfalls zwei Möglichkeiten zur Verfügung:

Deinstallation über Makefile

$ make uninstall

Manuelle Deinstallation

Wechselt in das Verzeichnis der Nautilus-Erweiterungen und löscht die Datei:

$ cd ~/.local/share/nautilus-python/extensions/
$ rm nautilus_copy_file_contents.py

Entwicklung und Debugging

Falls ihr Änderungen an der Erweiterung vornehmen oder sie debuggen möchtet, könnt ihr den Debug-Modus aktivieren, indem ihr im Terminal eine Umgebungsvariable setzt. Zum Aktualisieren wiederholt ihr einfach die Installation:

$ export NAUTILUS_PYTHON_DEBUG=misc
$ make install && nautilus -q
$ nautilus

Nun ist die Erweiterung bereit und hilft dir, den Inhalt von Dateien schnell und unkompliziert zu kopieren.

Sudoedit, das bessere sudo $editor

Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.

$ sudo -e /etc/hosts
$ sudoedit /etc/hosts

Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers in den Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechten.

$ VISUAL=gedit sudoedit /etc/hosts
$ EDITOR=nano sudoedit /etc/hosts

Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.

### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise
### über die ~/.bashrc oder 
$ grep EDITOR ~/.bashrc
export EDITOR=/usr/bin/joe
$ grep VISUAL ~/.xprofile
export VISUAL=/usr/bin/gedit
### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder
### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor
### Joe oder Gedit.
$ sudoedit /etc/hosts

Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoeditor funktioniert.

Root-Rechte für Files aka Nautilus

Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechner direkt in den Dateimanger einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.

In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaligen Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos walten und schalten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.

In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Browser bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.

Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.

Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.

Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien in den Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits schon einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.

Dateien stapelweise mit Nautilus umbenennen

Den Nautilus-Renamer findet ihr bei vielen Distributionen, wie zum Beispiel auch bei Ubuntu, noch nicht in den Paketquellen — obwohl das Programm bereits einige Jahre auf dem Buckel hat. Allerdings bietet das Projekt auf seiner Launchpad-Seite ein DEB-Paket zur Installation an, das ihr üblicherweise mit einem Doppelklick aus einem Dateimanager heraus installiert bekommt. Als Arch-User muss ich persönlich einfach nur ins AUR schauen, dort findet sich das Programm unter dem selben Namen. Damit die Nautilus-Erweiterung aktiv wird, müsst ihr den Dateimanager nach der der Installation des Pakets in jedem Fall einmal neu starten.

### Nautilus-Renamer unter Arch installieren...
$ pacaur -S nautilus-renamer
### Nautilus nach der Installation neu starten...
$ nautilus -q

Anschließend wird das Plugin automatisch geladen, auf den ersten Blick werdet ihr allerdings noch keinen großen Unterschied bemerken. Markiert ihr einfach nun nur eine Datei und wählt aus dem Kontextmenü heraus die Option Umbenennen an, beziehungsweise drückt auf [F2], dann öffnet Nautilus die herkömmliche Funktion zum Umbenennen einer einzigen Datei. Markiert ihr jetzt aber gleich mehrere Dateien im Dateimanager, dann startet Nautilus bei der selben Aktion automatisch die Stapelverarbeitung zum Umbenennen der Dateiauswahl.

Diese bietet nun drei Reiter: Muster lässt euch beim Umbenennen der Dateien alle Freiheiten. Über Variablen wie /name/, /day/, /number|3/ oder /number|3+5/ könnt ihr automatisch Teile des alten Namens übernehmen, den aktuellen Tag in die neuen Dateinamen einbauen oder die Dateien durchnummerieren — auf Wunsch auch bei einer bestimmten Zahl starten und vieles mehr. Der Button mit dem Fragezeichen neben dem Feld öffnet eine Quicklist mit allen zur Verfügung stehenden Schaltern.

Die anderen zwei Reiter, Ersetzen und Schreibweise, dienen für einfachere Aufgaben zum Suchen und Ersetzen beziehungsweise für Aktionen wie ALLES GROß SCHREIBEN, alles klein schreiben oder nur den Ersten Buchstaben groß schreiben. Habt ihr die gewünschte Umbenennen-Aktion eingegeben, dann solltet ihr noch kurz die Vorschau ausklappen und auf Vorschau aktualisieren tippen. Der Nautilus-Renamer zeigt euch dann die späteren Dateinamen an, sodass ihr etwaige Fehler schnell erkennen könnt. Dies ist natürlich besonders dann wichtig, wenn ihr mit den Mustern arbeitet.

Thunar als Alternative zu Nautilus

Als Alternative zu Nautilus bietet sich generell der Thunar-Dateimanager aus der Desktopumgebung Xfce an. Wie Gnome basieren auch die Xfce-Anwendungen auf GTK, sodass sich der Dateimanager gut in den Gnome-Desktop einpasst und bei Usern, die sowieso mit Gnome arbeiten, nur wenige Abhängigkeiten mehr installiert werden müssen — Allerdings bringt der Dateimanager eben von Haus aus einige Funktionen mit, die viele Anwender bei Nautilus vermissen. So lassen sich beispielsweise ohne weitere Nacharbeiten Dateien via Bearbeiten | Umbenennen oder [F2] im großen Stil umbenennen oder eine Baumansicht öffnen.

### Thunar unter Ubuntu installieren...
$ sudo apt install thunar
### Thunar unter Arch Linux installieren...
$ pacman -S thunar

In der Praxis fällt mir nun auf, dass die Let’s-Encrypt-Zertifikate zwar von den gängigen Browsern wie Chrome oder Firefox akzeptiert werden, das System selbst kommt mit den Zertifikaten jedoch noch nicht zurecht, da dieses das Let’s-Encrypt-Stammzertifikat in der Regel noch nicht kennt. Dies spürt man beispielsweise bei verschlüsselten WebDAV-Verbindungen, die man über den Dateimanager aufbauen möchte. Unter Gnome meldet Files (aka Nautilus) etwa recht wortkarg „Unbekannte Fehlermeldung: HTTP-Fehler: Nicht akzeptables TLS-Zertifikat“. Aufgrund eines uralten Bugs aus dem Jahr 2007 geht es danach auch nicht mehr weiter. Mit einem aktuellen Gnome-System lässt sich ein WebDAV-Share nicht verschlüsselt einbinden, egal ob Let’s Encrypt oder ein selbst-signiertes Zertifikat.

Das Geschehen kann man auch recht schön auf der Kommandozeile nachvollziehen: Nautilus macht nichts anderes als die WebDAV-Freigabe über das Gnome Virtual File System (aka GVFS) einzubinden, das entsprechende Kommando dafür lautet schlicht gvfs-mount gefolgt von der URL des entsprechenden Dienstes. Auch hier ist das Ergebnis wieder, dass GVFS den Verbindungsaufbau trotz explizierter Anweisung verweigert. Dasselbe würde übrigens auch mit einem selbst-signierten Zertifikat passieren, es sind also nicht nur Anwender von Let’s Encrypt von diesem Problem betroffen.

$ gvfs-mount davs://home.example.com:5006
Die Identität der Gegenseite kann nicht bestätigt werden:
	Die Zertifikats-Ausgabestelle ist unbekannt

Certificate information:
	Identity: home.example.com
	Verified by: Let's Encrypt Authority X1
	Expires: 02.03.2016
	Fingerprint (SHA1): 93 AD D4 91 ED 57 93 BF 53 D9 4D C2 4D D5 2D 39 1D 83 9C 95

Sind Sie absolut sicher, dass Sie fortsetzen wollen?
[1] Ja
[2] Nein
Choice: j
Fehler beim Einhängen des Ortes: HTTP-Fehler: Nicht akzeptables TLS-Zertifikat

Möchtet ihr nun nicht darauf verzichten euer NAS per verschlüsseltem WebDAV einzubinden, müsst ihr die Let’s-Encrypt-Stammzertifikate in eurem System installieren. Ihr könnt das jetzt manuell machen, oder ihr wartet bis der Distributor eurer Linux-Installation dies für euch erledigt — was je nach Distribution ein ganzes Weilchen brauchen kann. Mit den folgenden Kommandos ladet ihr die Let’s-Encrypt-Stammzertifikate aus dem Netz und installiert diese im System. Ein selbst-erstelltes Zertifikat ließe sich auf dem selben Weg einspielen, gebt bei Bedarf einfach den vollständigen Pfad zur Datei an.

$ wget https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem
$ sudo trust anchor lets-encrypt-x1-cross-signed.pem
$ sudo trust anchor lets-encrypt-x2-cross-signed.pem

Zur Kontrolle könnt ihr euch danach mit trust list die im System verfügbaren Zertifikate ausgeben lassen. Mit ein bisschen Grep-Magie sollte das Kommando dann nur die zwei neuen Let’s-Encrypt-Zertifikate ausspucken — wenn nicht, dann hat irgendwas mit der Installation der Zertifikate nicht funktioniert. Anschließend öffnet ihr wieder Nautilus und gebt abermals davs://home.example.com:port als URL in die Adresszeile ein. Diesmal sollte der Dateimanager das Zertifikat anstandslos akzeptieren und die verschlüsselte Verbindung zum NAS anstandslos aufbauen. Was ich hier mit Nautilus unter Gnome mache, sollte eigentlich auch mit den Dateimanagern anderer Desktopumgebungen funktionieren, also etwa bei KDE und Dolphin.

$ trust list | grep -C 2 "Let's Encrypt"
pkcs11:id=%a8%4a%6a%63%04%7d%dd%ba%e6%d1%39%b7%a6%45%65%ef%f3%a8%ec%a1;type=cert
    type: certificate
    label: Let's Encrypt Authority X1
    trust: anchor
    category: authority
--
pkcs11:id=%c5%b1%ab%4e%4c%b1%cd%64%30%93%7e%c1%84%99%05%ab%e6%03%e2%25;type=cert
    type: certificate
    label: Let's Encrypt Authority X2
    trust: anchor
    category: authority

Solltet ihr die Stammzertifikate (oder ein entsprechend selbst-signiertes) später einmal wieder vom System löschen wollen, dann hängt an das Kommando trust anchor einfach noch ein --remove mit dem Pfad zur Zertifikat-Datei oder der entsprechenden PKCS-Kennung an. Achtet dabei bitte darauf kein wirklich wichtiges Zertifikat zu löschen, sonst weigert sich beispielsweise die Paketverwaltung mit den Paketquellen zu sprechen oder es lassen sich viele verschlüsselte Webseiten nicht mehr öffnen.

$ trust anchor --remove /pfad/zu/zertifikat.crt
$ trust anchor --remove "pkcs11:id=%AA%BB%CC%DD%EE;object-type=cert"

Das Problem lässt sich leider aus meiner Erfahrung heraus nicht grafisch lösen. In Nautilus fehlt bei Ordnern im Kontextmenü der Reiter „Öffnen mit“, in dem man die Zuordnung wie bei Dateien üblich korrigieren könnte. Weiß man man aber machen muss, ist die Lösung allerdings nicht sonderlich aufwändig, man muss sie nur in den Tiefen des Internets finden. In meinem Fall führte ein kurzer Beitrag auf bbs.archlinux.org zum Ziel, der auch gleich die Lösung des Problems beinhaltet. Die Ursache des Problems liegt in einem Bug, bei dem durch die Installation von Anjuta (oder auch anderer Apps) der Mime-Eintrag für Verzeichnisse verbogen wird, es gilt also diesen zu korrigieren.

$ xdg-mime query default inode/directory
anjuta.desktop

$ xdg-mime default nautilus.desktop inode/directory

$ xdg-mime query default inode/directory
nautilus.desktop

Die Befehle zeigen die verbogene Zuordnung von Ordnern an und korrigiere diesen gleich wieder. Unmittelbar nach dem Ausführen des zweiten Kommandos öffnen sich Ordner wieder mit Nautilus. Beachtet aber bitte, dass die Zuordnung nun nur für euren aktuellen Benutzer stimmt, bei anderen Usern des Systems öffnet sich nach wie vor Anjuta. Ihr müsst den zweiten Befehl daher für alle Benutzer des Systems ausführen, eine globale Lösung gibt es meines Wissens aktuell nicht.

//EDIT: Im AUR findet man mit gnome-defaults-list ein Paket, dass die Dateizuordnungen global für alle Benutzer des Systems korrigiert. Das ist für Mehrbenutzersysteme wahrscheinlich einfacher, als jedem User den Befehl zu vermitteln.

Sollte ihr auf einem Linux-System die Daten seines Handys per USB einsehen wollen, dann sollte man auf jeden Fall erst einmal kurz unter Einstellungen -> Speicher -> USB-Verbindung überprüfen, ob das Handy sich als Mediengerät (MTP) verbindet. Dies ist inzwischen bei den meisten Android-Handys der Fall, nur manche Geräte mit einem zusätzlichen microSD-Kartenslot bilden hier noch eine Ausnahme, auf diesen Teil des Speichers kann man ab und an noch per USB-Massenspeichermodus — und somit auch ohne weitere Basteleien — zugreifen, da das Handy in diesem Fall wie ein USB-Speicherstick arbeitet.

Wer unter Arch nun mit GNOME, der GNOME Shell und/oder Nautilus (bzw. jetzt Dateien oder Files genannt) arbeitet, der muss das Gnome Virtual File System mitsamt dem Modul für die MTP-Unterstützung nachinstallieren. Dies geschieht nicht automatisch, wenn man GNOME mitsamt seiner Abhängigkeiten aus der Paketverwaltung zieht. Nach der Installation der zwei Pakete taucht umgehend beim Anstecken des Handys unter „Geräte“ euer Android-Smartphone oder -Tablet auf.

$ sudo pacman -S gvfs gvfs-mtp

Unter Arch Linux arbeitet GVFS zusammen mit MTP absolut sauber. Ich sehe alle auf dem Handy enthaltenen Daten und kann sie vom Handy löschen, verschieben oder kopieren. Natürlich kann ich auch neue Dateien aufs Handy schaufeln. Vergleiche ich den MTP-Support zu Debian Jessie/Testing, dann muss ich sagen, dass der MTP-Zugriff unter Arch deutlich besser funktioniert. Unter Debian verlieren vom Handy kopierte Dateien ihren Dateinamen (sie bekommen einfach nur eine fortlaufende Nummer) und auch der Transfer größerer Dateimengen bricht ab — das passiert unter Arch nicht! Daher die Frage an die Ubuntu-User, funktioniert das auf aktuellen Ubuntu-Systemen sauber?

Richtig brauchbar und umfassend fand ich dagegen die Erweiterung Nautilus Renamer, ihr könnt sie unter Debian/Ubuntu direkt über ein .deb-Paket installieren, den Download findet ihr auf der rechten Spalte der entsprechenden Launchpage-Seite. [UPDATE: Unter Arch findet sich die Software inzwischen im Arch-User-Repository aka AUR. Aus diesem lässt sich das Programm mithilfe eines AUR-Helpers daher sehr leicht installieren, ohne dass man sich um das Auflösen von Abhängigkeiten oder die Installation von Bibliotheken zum Kompilieren beschäftigen müsste.]

$ pacaur -Ss nautilus renamer
aur/nautilus-renamer 4.0-1 (34, 0,49) [installed]
    Rename multiple files easily in Nautilus (Files).
$ pacaur -S nautilus-renamer

Nach der Installation des Pakets und einem Neustart des Dateimanagers (am einfachsten über ein Terminal und den Befehl $ nautilus -q && nautilus &) findet ihr im Kontextmenü von Nautilus den neuen Eintrag „Mass Rename“, sobald ihr mehrere Dateien ausgewählt habt. Über diesen könnt ihr dann Dateien nach einem bestimmten Schema umbenennen, Namensteile lassen sich Ersetzen oder ihr ändert einfach nur die Schreibweise wie etwa die Groß-/Kleinschreibung. Das einziges große Manko ist in meinen Augen, dass Nautilus-Renamer wohl nicht mit via GVFS eingebundenen Netzwerk zurecht kommt, auf einem FTP-Server versagte das Programm leider seinen Dienst. Für diesen Fall müsste man die Netzwerkfreigabe komplett im System mounten.

Die Installation der Erweiterung kann direkt aus dem PPA des Entwicklers erfolgen. Der übliche Dreisprung aus Quelle einbinden, Quellen neu einlesen und Paket installieren bringt einen unter Ubuntu zum Ziel. Abschließend muss Nautilus noch komplett neu gestartet werden.

$ sudo add-apt-repository ppa:flozz/flozz
$ sudo apt-get update
$ sudo apt-get install nautilus-terminal
$ killall nautilus

Danach erscheint automatisch beim Start des Dateimanagers ein Terminal im oberen Bereich des Anwendungsfensters. Über den „Griff“ zwischen Terminal und Dateien könnt ihr das Terminal vergrößern oder eben auch komplett reduzieren, so dass man es nicht mehr sieht. Alternativ könnt ihr auch das Terminal mit [F4] aus und wieder einblenden. Des weiteren könnt ihr Dateien aus dem Dateimanger ins Terminal ziehen, so dass der Pfad der Datei übernommen wird und Inhalte mit [Strg]+[Shift]+[C] bzw. [Strg]+[Shift]+[V] kopieren bzw. auch wieder einfügen.

Solltet ihr das Terminal permanent anpassen wollen, so könnt ihr das über die Konfigurationsdatei ~/.nautilus-terminal machen. Die Datei existiert von Haus aus nicht, daher müsst ihr sie mit einem Editor anlegen…

$ gedit ~/.nautilus-terminal

…und dann z.B. diese Zeilen einfügen. Über sie könnt ihr die Höhe des Terminalbereiches bestimmen, die Position des Terminals angeben und auch sagen ob das Terminal von Haus aus Sichtbar sein soll. Optional könnt ihr auch noch angeben, dass eine andere Shell benutzt werden soll.

[general]
#The terminal height (lines)
def_term_height=5
#The terminal default visibility in new windows? (1: Visible, 0: Hidden)
def_visible=1
#The terminal position (1: Top, 0: Bottom)
#NOTE: it's not recommended to put the terminal on the bottom
term_on_top=1

[terminal]
#The shell to use (Nautilus Terminal use the user's defined shell by default)
shell=/bin/bash

Nautilus Terminal ist sicherlich eine tolle Ergänzung zum Dateimanager. Ich hab die Erweiterung bei mir so eingestellt, dass ich sie von Haus aus ausgeblendet ist und erst mit F4 sichtbar wird. So hab ich immer ein Terminal mit dem aktuellen Ordner zur Hand, ohne dass ich mir den Desktop mit Terminalfenstern zukleistern muss.

$ sudo apt-get remove nautilus-open-terminal

…sollte alles wieder normal sein und Nautilus zuverlässig arbeiten. Vielleicht auch gleich noch ein zweiter Hinweis für GNOMEler. Nautilus-Erweiterungen, wie die neue Erweiterung nautilus-image-manipulator, die auf Nautilus-Python setzen sind wohl ALLE defekt, da nautilus-python buggy ist. Nautilus wurde in Oneiric wohl etwas arg vernachlässigt, mich persönlich trifft das Fehlen von Nautilus-Open-Terminal ziemlich hart, da ich diese Funktion gerne benutzt habe.