try: Befehle vorab ausführen und ihre Dateieffekte prüfen, bevor sie ins System gehen

try als Befehl höherer Ordnung: erst ausführen, dann committen

try ordnet sich in die Familie der Befehle höherer Ordnung ein, wie das README neben xargs, nohup und find schreibt: Man stellt ihn vor einen anderen Befehl, etwa try pip3 install libdash, und der Befehl läuft in einer Overlay-Umgebung. Nach dem Ende zeigt try, welche Dateien geändert wurden, und fragt, ob die Änderungen übernommen werden sollen. Verneint man, wirft man die Effekte weg, bejaht man, wandern sie ins Live-System.

Das Projekt stammt aus dem binpash-Umfeld, ist in Shell geschrieben, MIT-lizenziert und zählt 5490 Sterne bei 79 Forks. Die Forschungskomponente ist sichtbar: try erhielt laut README auf der OSDI'26 sowohl einen Best-Paper- als auch einen Distinguished-Artifact-Award, und für das Design verweist das Dokument auf den dortigen Vortrag. Der Skelettvertrag lautet: nichts verändern, bevor man gesehen hat, was verändert würde. Damit adressiert das Werkzeug das bekannte Risiko von Installations- und Bootstrap-Skripten, die ihr eigenes Fußabdruckmuster verschweigen.

unshare und overlayfs: die Mechanik hinter dem Semisolat

Unter der Haube stehen zwei Linux-Bausteine, die das README benennt: Namespaces über unshare und das Union-Dateisystem overlayfs. try legt eine Overlay-Umgebung an, in der Schreibvorgänge des Befehls in einer oberen Schicht landen, während das echte System unverändert darunter bleibt. Genau diese Trennung macht die Prüfung vor dem Commit möglich.

Wichtig ist die Selbstverortung: try ist ein Semisolat, ausdrücklich keine Sandbox. Netzwerkaufrufe bleiben vollständig erlaubt, und das README warnt, das Werkzeug nicht für Befehle einzusetzen, denen man ohnehin nicht vertraut. Es deckt also einen anderen Fall ab: Man will einen Befehl ausführen, kennt aber nicht seine Dateisystemwirkung. Für Schadcode-Eindämmung fehlen die Kontrollen, und der Unterschied zwischen Semisolat und Sandbox wird im OSDI-Paper ausgearbeitet. Wer die Grenze übersieht, hat Sicherheit, die es nicht gibt; wer sie respektiert, bekommt ein Prüfinstrument ohne Zeremonie.

try -n, try -N und try summary: Änderungen inspizieren und stapeln

Die Kontrolle läuft über drei Wege. Voreingestellt fragt try am Ende vor dem Übernehmen. Der Schalter -n erzwingt die Aufschubvariante: try -n "curl https://sh.rustup.rs | sh" gibt nur den Pfad des Overlay-Verzeichnisses auf STDOUT aus, im Beispiel /tmp/tmp.uCThKq7LBK, und committet nicht. Mit -N [dir] nutzt try ein bestehendes Verzeichnis; das Beispiel rustup-sandbox zeigt danach die drei Einträge temproot, upperdir und workdir.

Die Inspektion ist bewusst grobkörnig: Im upperdir zeigt du -hs eine Rustup-Installation mit 1,2 Gigabyte Änderungen, und try summary rustup-sandbox/ listet die betroffenen Dateien mit Status wie modified/added, darunter .profile, .bashrc und Dateien unter .rustup/toolchains. Übernommen wird mit try commit rustup-sandbox, und try explore öffnet die aktuelle Shell innerhalb eines Sandbox-Verzeichnisses. Mit -L lässt sich eine durch Doppelpunkte getrennte Liste mehrerer unterer Verzeichnisse zusammenführen, das linkeste hat Vorrang, und der Schalter impliziert -n. So lassen sich mehrere Sandboxes stapeln und schrittweise bewerten.

Installation: Skript in den PATH, autoconf-Build oder try-latest.tgz

Drei Installationswege stehen bereit. Der schnelle: Nur das try-Skript aus dem Repository herunterladen, in den PATH legen, fertig, ohne Doku und ohne Hilfswerkzeuge. Der vollständige: git clone https://github.com/binpash/try.git, dann autoconf && ./configure && make && sudo make install, was Hilfsprogramme für schnellere Ausführung und die Manpage bringt; make test bestätigt die Funktion. Der dritte Weg nutzt die Quellverteilung try-XXX.tgz von der Release-Seite oder try-latest.tgz, die bereits das configure-Skript und die Manpage enthält, die dem Klon fehlen, weil beide erst von autoconf bzw. pandoc erzeugt werden.

Dazu kommen Paketquellen: Auf Arch Linux liegt try im AUR, installierbar mit yay -S try oder manuell über git clone des AUR-Pakets und makepkg -sic. Für Nix und NixOS genügt nix-shell -p try, die Pflege im nixpkgs übernimmt laut README das Projekt selbst. Als Abhängigkeiten nennt das Dokument die Debian-Pakete attr für getfattr sowie pandoc und autoconf, letztere nur beim Arbeiten aus einem Klon. Die Testsuite in scripts/run_tests.sh verlangt bash, expect und curl.

Kernel-Grenze 5.11 und getestete Distros von Ubuntu bis SteamOS

Eine harte Voraussetzung steht im README: overlayfs funktioniert in einem Benutzernamespace erst ab Linux 5.11, verwiesen wird auf den zugehörigen Kernel-Commit. Ältere Kernel scheiden damit aus, egal wie aktuell die Distribution sonst ist. In Fällen, in denen overlayfs bei verschachtelten Mounts nicht arbeitet, greift try laut README automatisch auf mergerfs oder unionfs zurück; mit -U lässt sich ein Pfad erzwingen, etwa try -U ~/.local/bin/unionfs.

Die Liste der getesteten Distributionen ist konkret: Ubuntu 20.04 LTS oder neuer, Debian 12, Fedora 38, CentOS 9 Stream 5.14.0-325.el9, Arch 6.1.33-1-lts, Alpine 6.1.34-1-lts, Rocky 9 5.14.0-284.11.1.el9_2 und SteamOS 3.4.8 mit dem Kernel 5.13.0-valve36-1-neptune. Diese Breite inklusive SteamOS zeigt, dass auch Handheld- und Spielkonsolen-Umgebungen einbezogen wurden. Continuous Integration läuft über GitHub Actions mit der Workflow-Datei test.yaml, sodass jeder Push auf dem Testset durchläuft. Für die eigene Umgebung bleibt die Entscheidung simpel: Kernel-Version prüfen, dann einen der Testbefehle ausführen.

Grenzen: UID- und GID-Abbildung sowie Shell-Zitierung

Zwei dokumentierte Schwächen sind wichtig. Erstens scheitern Befehle, die mit anderen Benutzern oder Gruppen interagieren, weil try nur die Kennung des aktuellen Nutzers abbildet; Systempakete, die eigene Servicekonten anlegen wollen, sind damit ein problematischer Fall. Das README verweist auf einen Zweig namens future, in dem Unterstützung für UID- und GID-Abbildung entsteht.

Zweitens ist die Zitierung unintuitiv: try bash -c "echo a" wird als try bash -c echo a geparst und gibt kein a aus. Wer komplexe Shell-Ausdrücke kapselt, sollte daher auf eine Skriptdatei ausweichen statt Inline-Quotes zu verschachteln; der Unterschied liegt im Zeitpunkt der Auflösung, die hier durch try und nicht durch die eigene Shell geschieht. Die Release-Historie zeigt eine ruhige Entwicklung: v0.1.0 vom 25. Juni 2023, v0.2.0 vom 24. Juli 2023, und daneben ein laufend erneuerter Tarball-Tag latest, zuletzt am 28. August 2026. Die MIT-Lizenz erlaubt Nutzung, Veränderung und Vertrieb frei, hält aber keinerlei Gewährleistung bereit, was zur Forschungsnatur des Projekts passt.

Redaktionelles Fazit

try passt für Linux-Nutzer ab Kernel 5.11, die Systemänderungen von Installations- oder Skriptbefehlen vor dem Übernehmen prüfen wollen, und die verstehen, dass Netzwerkzugriffe offen bleiben. Ungeeignet ist es zur Ausführung nicht vertrauenswürdiger Programme, dazu scheitern Befehle mit anderen Benutzern oder Gruppen. Vor dem produktiven Gebrauch lohnt make test nach dem Build und ein Probelauf von try pip3 install mit einem ungefährlichen Paket.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes