Ereignisgesteuerte Automatisierung unter macOS mit Crank

Crank ist ein Programm, das im Hintergrund läuft und verschiedene Aktionen ausführen kann, wenn im System irgendwas passiert. So kann Crank darauf reagieren, wenn ein Kopfhörer über Bluetooth verbunden wird oder ein Screenshot in einem Ordner landet. Cranks Aufgabe ist es, auf bestimmte Ereignisse zu lauschen, die als Trigger definiert sind, und daraufhin eine Aktion anzustoßen. Dabei funktioniert Crank ähnlich wie Shortery, das allerdings nur als Aktion die Ausführung von Apple Kurzbefehlen unterstützt. Auch in Crank können Kurzbefehle als Aktion genutzt werden, darüber hinaus Skripte, die in unterschiedlichen Sprachen geschrieben sind.

Da ich mich für die Automatisierung unter macOS und das Erstellen von Skripten interessiere, fand ich den Ansatz von Crank interessant und wollte mir das Programm genauer ansehen. Das Entwicklerteam The low-tech guys hat mir dafür freundlicherweise eine Kopie von Crank zur Verfügung gestellt. Dass Crank mit dem Slogan „Effortless macOS automation – no manual required“ („Mühelose Automatisierung unter macOS – ganz ohne Anleitung“) beworben wird, machte mich zusätzlich neugierig.

Crank bietet mehr als 30 Trigger. Sie reagieren auf Änderungen im System, zum Beispiel auf die Anmeldung an ein WLAN-Netz, das Anschließen eines USB-Gerätes, einen neuen Inhalt in der Zwischenablage oder den Wechsel des Fokus-Modus. Als Reaktion darauf kann Crank folgende Aktionen ausführen:

Benachrichtigen: Mitteilung anzeigen
Öffnen: App starten, URL öffnen, Datei öffnen
Automatisieren: Kurzbefehl, AppleScript oder Shell-Skript ausführen (zsh, Python 3, Ruby, Perl, Swift oder ein eigener Interpreter)
Crank steuern: Profil aktivieren, Regel aktivieren oder deaktivieren

Das Programm kostet zum Zeitpunkt dieses Tests als Einmalkauf 10,00 € (Oktober 2026) statt des regulären Preises von 14,28 €. Außerdem lässt es sich 14 Tage kostenlos testen. Vorausgesetzt wird macOS 14.0 (Sonoma) oder neuer.

Das User Interface

Das UI ist relativ selbsterklärend, wenn auch nicht ganz Apple-konform. In der Titelleiste befinden sich einige Funktionen. Mit den Schaltflächen unter (1) kann man den linken Triggerbereich ein- und ausklappen, die Einstellungen öffnen (⌘,), die Befehlspalette aufrufen (⌘K) und die Darstellung der Regeln (6) zwischen der hier gezeigten Listenansicht und einer Tabellenansicht umschalten.

Mit dem Umschalter unter (2) wechselt man zwischen drei Ansichten, der „Trigger“-Ansicht, dem Event-Log (⌘2) und der „Action History“ (⌘3). Die Ansicht „Trigger“ ist die Hauptansicht. Sie besteht aus der Trigger-Liste (1) und dem Regelbereich (6), der die Regeln als Liste von Regelboxen zeigt. Im Event-Log werden alle Ereignisse angezeigt, die das System auslöst und auf die Crank achtet. In der Action History werden die ausgeführten Aktionen samt ihrer Ausgaben und etwaiger Fehler aufgelistet.

Der Button unter (3) ist ein Menü und zeigt den Namen des aktiven Profils an. Aufgeklappt bietet es Funktionen, um Profile zu verwalten und neue Profile anzulegen, in denen dann neue Regeln erstellt werden können. Mit Profilen lässt sich zum Beispiel festlegen, dass am Arbeitsplatz ein anderes Regelset aktiv ist als zu Hause. Über das Kontextmenü (rechte Maustaste) einer Regel kann man sie in ein anderes Profil verschieben.

Im Bereich (4) stehen die Funktionen der Werkzeugleiste, die hier vergrößert dargestellt ist:

Alle Regeln aktivieren
Alle Regeln deaktivieren
Alle Gruppen ausklappen
Alle Gruppen einklappen
„DryRun“: Versetzt das gesamte System in einen Testmodus, in dem Crank weiterhin die Bedingungen der Regeln prüft und das Ergebnis in der Action History protokolliert, die Aktionen aber nicht ausführt
Das Löschen einer Regel rückgängig machen
Die gesamten Einstellungen als Backup speichern, nicht mit dem Teilen-Button verwechseln
Ein Backup wieder laden

Das Event-Log

Das Event-Log (2) ermöglicht einen Überblick über die möglichen Ereignisse, auf die Crank reagieren kann, wenn unter (1) „All Triggers“ aktiv ist. Zum Debuggen lassen sich die Einträge mit „Enabled Rules Only“ auf die Ereignisse beschränken, für die aktive Regeln existieren.

Im Dropdown-Menü (3) kann das Log nach den Trigger-Bereichen gefiltert werden. Der Papierkorb (5) leert das Log, und über die Suche (6) kann man gezielt nach einem Eintrag suchen.

Die Action History

In der Action History werden die ausgeführten Aktionen protokolliert. Jeder Eintrag nennt die Uhrzeit, die Regel, den auslösenden Trigger und die Aktion. Läufe, die im DryRun entstanden sind, sind mit „DRY RUN“ gekennzeichnet. Klappt man einen Eintrag auf (3), sieht man die Ausgaben des Skripts, den Exit-Code mit der Laufzeit und die Werte des auslösenden Ereignisses.

Die rote Schrift ist dabei nicht unbedingt ein Fehler. Rot dargestellt wird die Standardfehlerausgabe (stderr) des Skripts, und die enthält auch normale Statusmeldungen, hier etwa den neuen Namen, unter dem der Screenshot abgelegt wurde. Ob eine Aktion erfolgreich war, zeigt der Exit-Code. Eine 0 (grün) steht für Erfolg, alles andere (rot) für einen Fehler. So wurde das Skript im unteren Eintrag nach 30 Sekunden abgebrochen („Script timed out after 30 seconds“, Exit ‑1).

Das Warndreieck (1) filtert die Einträge nach Aktionen, die nicht mit dem Exit-Code 0 enden, die also nicht zum gewünschten Ergebnis geführt haben. Der Papierkorb (1) leert die Liste, und über die Suche (2) lassen sich einzelne Einträge finden.

Der Aufbau von Regeln

Eine Regel beginnt immer mit einem Trigger, der zunächst in der linken Seitenleiste (1) ausgewählt wird. In diesem Beispiel ist das „File/Folder changes“ → „created“. Mit der Auswahl wird die Regel neu angelegt und die erste Zeile „WHEN“ (2) erstellt. Sie legt fest, dass auf Ereignisse reagiert werden soll, die Änderungen im Dateisystem melden. Obwohl die Seitenleiste an dieser Stelle von „Files“ spricht, reagiert der „File Watcher“ auch auf Ordner, die erstellt, geändert oder gelöscht werden.

In der nächsten Zeile „IF“ (3) wird eine Bedingung festgelegt, die genauer eingrenzt, auf welche Dateien oder Ordner geachtet werden soll. Im Beispiel muss der Dateiname den Text „Bildschirm“ enthalten.

Die Zeile „THEN“ (4) legt fest, welche Aktion ausgeführt werden soll, etwa ein Kurzbefehl, ein AppleScript, ein Skript oder einfach nur eine Mitteilung. Im Beispiel ist es „Run Shell Script“. Der Timeout, der hier angezeigt wird (im Beispiel eine Minute), wird unter der Skript-Box (5) eingestellt.

In der folgenden Zeile (6) wird der Ort festgelegt, der beobachtet werden soll („Watch Path“), und ob auch Unterordner einbezogen werden („Recursive“).

Soll, wie in diesem Beispiel, ein Skript ausgeführt werden, lässt sich über (7) der Interpreter auswählen. Neben zsh, Python 3, Ruby, Perl und Swift kann auch ein eigener Interpreter angegeben werden.

In der Box (8) wird das Skript eingegeben. Rechts daneben (9) stehen die Variablen, die im Skript genutzt werden können, etwa $fileName und $filePath. Auf den Button am unteren Rand der Skript-Box („Generate code“) gehe ich weiter unten ein.

Je nach Interpreter erscheinen zusätzliche Optionen. Für ein zsh-Skript lässt sich über die Checkbox „Load ~/.zshrc“ (10) festlegen, ob die persönliche Konfigurationsdatei der Shell mitgeladen werden soll. Mit „Run“ (10) kann das Skript direkt ausgeführt werden. Ein Swift-Skript kann auf Wunsch auch kompiliert werden, was vermutlich erst sinnvoll ist, wenn das Skript fertig ist, aber dann die Ausführung deutlich beschleunigt.

Unterhalb der Skript-Box befinden sich Einstellungen, welche die Ausführung des Skripts beeinflussen. Der Timeout (5) stellt sicher, dass ein Skript, das aus irgendeinem Grund zu lange läuft, abgebrochen wird. So kann ein hängendes Skript nicht endlos weiterlaufen. Wird der Timeout überschritten, steht in der Action History „Script timed out“ mit dem Exit-Code ‑1, wie im Beispiel oben.

Darunter folgen die Einstellungen „Rate Limit“, „Schedule“ und „Conditions“ (11). Im Dropdown-Menü „Rate Limit“ lässt sich einstellen, wie sich die Regel verhalten soll, wenn ein Ereignis mehrmals schnell hintereinander ausgelöst wird. Ein Beispiel ist das Schließen eines MacBooks. Dabei wird das Ereignis „LidAngle“ ausgelöst, das sich mehrfach wiederholen kann. Mit der Option „Throttle“ wird die Aktion schon beim ersten Auftreten ausgeführt, und alle weiteren Ereignisse werden für ein festgelegtes Zeitfenster ignoriert. Mit „Debounce“ wartet die Regel dagegen eine festgelegte Zeit ab, bevor die Aktion ausgeführt wird. Im Fall von „LidAngle“ erscheint mir „Debounce“ sinnvoller, weil die Aktion dann erst nach der Wartezeit ausgeführt wird und nicht schon bei der ersten Änderung des Winkels. (Ausprobiert habe ich das nicht.)

Mit der Option „Schedule“ lässt sich festlegen, an welchen Wochentagen und in welchem Zeitfenster die Regel aktiv sein soll. Unter dem Schalter „Conditions“ können außerdem weitere Bedingungen definiert werden, die zum Trigger gehören. Achtet der File Watcher wie im Beispiel auf einen bestimmten Dateinamen (3) in einem festgelegten Ordner (6), kann hier zusätzlich eingestellt werden, dass nur Änderungen an Ordnern, nicht an Dateien, berücksichtigt werden. Die Bedingungen sind damit auf drei Stellen verteilt, nämlich den Dateinamen in der IF-Zeile (3), den Ort im „Watch Path“ (6) und weitere unter „Conditions“. Warum sie nicht an einer Stelle zusammenlaufen, erschließt sich mir nicht.

Mit der letzten Option (12), „Also run an action when the file is deleted“, kann zusätzlich eine Aktion für das gegenteilige Ereignis definiert werden, hier das Löschen der Datei. Wird der Schalter umgelegt, erscheint im oberen Teil der Regel eine zweite „WHEN“-Zeile mit dem gegenteiligen Trigger („file deleted“), für den eine eigene Aktion festgelegt werden kann (siehe Bild). Auch hier erschließt sich mir nicht, warum der Schalter unten in der Regel platziert ist und nicht dort, wo anschließend die Definition stattfindet.

Regeln und Skripte mit KI erstellen

Eine Regel zu erstellen ist ziemlich einfach. Zuerst wird der passende Trigger ausgesucht, dann die Bedingung festgelegt und schließlich eine Aktion gewählt. Einfache Aktionen, etwa eine Mitteilung, wenn der Akkustand unter einen bestimmten Wert sinkt, oder das Öffnen einer URL beim Start des Rechners, lassen sich schnell zusammenklicken. Wird die Aktion komplexer, wird es aufwendiger. Der vielleicht einfachste Weg ist dann ein Apple Kurzbefehl als Aktion, denn mit macOS 27 unterstützt Apple dessen Erstellung mithilfe von „Apple Intelligence“. Es genügt, zu beschreiben, was der Kurzbefehl tun soll. Den Rest erledigt Apple Intelligence.

Der Code-Generator in Crank

Crank geht mit dem eingebauten Code-Generator einen ähnlichen Weg. In den Einstellungen unter „Advanced“ kann ein kostenloser API-Key von Google Gemini eingetragen werden. Den Key legt man mit einem kostenlosen Google-Account auf aistudio.google.com/api-keys an. Alternativ kann ChatGPT über Apple Intelligence genutzt werden. Dazu installiert Crank Apple Kurzbefehle, die als Schnittstelle dienen.

Bei einer neuen Regel gibt man nun statt eines Skripts eine Anweisung ein, hier mit der Bitte, ein Swift-Skript zu erstellen:

Create a Swift script that speaks the file name and the path when a new file is created in the folder, in German: Die Datei wurde im Pfad erstellt

Nach einem Klick auf „Generate code“ wird das Skript erstellt. In diesem Beispiel unter Verwendung von meines kostenlosen ChatGPT Account über die „Apple Intelligence“ Schnittstelle, weil der Aufruf der Gemini-API in meinem kostenlosen Account immer mal wieder wegen Überlastung abgebrochen wird.
.
Als Ergebnis wird, nachdem man die Ausführung des Kurzbefehls genehmigt hat, das fertige Skript anstelle des Prompts eingetragen:

#!/usr/bin/swift
import Foundation

let env = ProcessInfo.processInfo.environment
guard let fileName = env["fileName"], let filePath = env["filePath"] else {
    exit(1)
}

let message = "Die Datei \(fileName) wurde im Pfad \(filePath) erstellt"

let task = Process()
task.launchPath = "/usr/bin/say"
task.arguments = [message]
task.launch()
task.waitUntilExit()

exit(0)

Crank per MCP steuern

Die zweite Möglichkeit besteht darin, dass eine KI wie Claude, entweder in der Desktop-App oder mit Claude Code im Terminal, Crank direkt steuert. Dazu muss zunächst in den Einstellungen unter „General“ das „crank command line tool“ installiert werden.

Anschließend lässt sich unter „AI agents“ der Crank MCP-Server starten („Enable MCP“), der mit einem KI-Agenten verbunden wird, hier mit Claude Code und der Claude-Desktop-App. MCP („Model Context Protocol“) ist eine Schnittstelle, über die KI-Anwendungen externe Werkzeuge ansprechen können. Crank unterstützt außerdem weitere KI-Agenten, etwa Codex von OpenAI, die Copilot CLI von GitHub, OpenCode und die Gemini CLI von Google.

Damit lassen sich Regeln per Prompt direkt in der App oder im Terminal-Tool des jeweiligen KI-Anbieters erstellen. Claude verbindet sich dazu mit Crank, holt sich die nötigen Informationen, erstellt den Code und testet ihn.

Am Ende wird die fertige Regel direkt in Crank angelegt, hier mit der Bezeichnung „Desktop: neue Datei ansagen“.

So kann selbst jemand, der die Syntax einer Skriptsprache nicht kennt, auch komplexere Skripte erstellen lassen. Etwas Programmiererfahrung sollte aber vorhanden sein, um zumindest grob zu verstehen, was das Skript macht.

Eigene Trigger per Skript

Reichen die vorhandenen Trigger nicht aus, bietet Crank die Möglichkeit, einen eigenen Trigger zu schreiben. Statt auf ein Systemereignis zu achten, führt Crank dazu in regelmäßigen Abständen ein Skript aus und entscheidet anhand des Exit-Codes, ob die Regel auslöst. Als Beispiel habe ich mir von Claude als KI-Agent eine Regenwarnung umsetzen lassen. Das Skript fragt für einen festgelegten Ort die Regenprognose der nächsten zwei Stunden ab. Wird Regen erwartet, erscheint eine Mitteilung, die angibt, wann der Regen beginnt und wie viel zu erwarten ist. Das Skript sieht so aus:

import json, sys, urllib.request
from datetime import datetime

# Koordinaten für Heidelberg
LAT, LON = 49.40, 8.68
THRESHOLD_MM = 0.5   # Summe der nächsten 2 Stunden

URL = (f"https://api.open-meteo.com/v1/forecast?latitude={LAT}&longitude={LON}"
       "&minutely_15=precipitation&forecast_minutely_15=8&timezone=Europe%2FBerlin")

# 1 Daten holen, bei jedem Fehler still abbrechen
try:
    with urllib.request.urlopen(URL, timeout=5) as r:
        data = json.load(r)
    times = data["minutely_15"]["time"]
    rain = data["minutely_15"]["precipitation"]
except Exception:
    sys.exit(1)

# 2 Entscheiden, Exit 1 bedeutet nichts tun
total = sum(x or 0 for x in rain)
if total < THRESHOLD_MM:
    sys.exit(1)

# 3 Beginn des Regens und Wartezeit bestimmen
first = next((t for t, x in zip(times, rain) if (x or 0) > 0), times[0])
minutes = max(0, int((datetime.fromisoformat(first) - datetime.now()).total_seconds() // 60))

# 4 Daten für die Aktion ausgeben
print(f"mm={total:.1f}")
print(f"start={first[11:16]}")
print(f"minutes={minutes}")

Eingetragen wird das Skript beim Trigger „Script“. Crank führt es alle 600 Sekunden aus („Poll every“). Endet es mit dem Exit-Code 0, löst der Trigger aus, bei jedem anderen Exit-Code wird die Regel übersprungen. Zeilen im Format schlüssel=wert, die das Skript ausgibt, stehen der Aktion als Platzhalter {{schlüssel}} zur Verfügung.

Was macht das Skript?

Im Kopfbereich werden die benötigten Bibliotheken geladen und Variablen definiert, nämlich die Geokoordinaten (hier Heidelberg) und der Schwellenwert, ab dem Regen gemeldet wird.

Die Variable URL enthält die Adresse des Wetterdienstes Open-Meteo, über die die Regenmengen der nächsten zwei Stunden abgerufen werden. Der Parameter minutely_15=precipitation legt fest, dass die Niederschlagsmenge abgerufen werden soll, und forecast_minutely_15=8 fordert acht Werte im Abstand von 15 Minuten an, also zwei Stunden.

import json, sys, urllib.request
from datetime import datetime

# Koordinaten für Heidelberg
LAT, LON = 49.40, 8.68
THRESHOLD_MM = 0.5   # Summe der nächsten 2 Stunden

URL = (f"https://api.open-meteo.com/v1/forecast?latitude={LAT}&longitude={LON}"
       "&minutely_15=precipitation&forecast_minutely_15=8&timezone=Europe%2FBerlin")

Als Nächstes werden die Wetterdaten über die URL abgerufen. Die Antwort von Open-Meteo ist ein JSON mit den Vorhersagedaten der nächsten zwei Stunden in 15-Minuten-Schritten. Daraus werden die Uhrzeiten in der Liste timesund die Niederschlagsmengen in der Liste rain abgelegt, wobei die Einträge an derselben Position zusammengehören. Schlägt der Aufruf fehl, etwa weil der Dienst nicht erreichbar ist oder nicht innerhalb von fünf Sekunden antwortet, wird das Skript mit dem Exit-Code 1 beendet.

# 1 Daten holen, bei jedem Fehler still abbrechen
try:
    with urllib.request.urlopen(URL, timeout=5) as r:
        data = json.load(r)
    times = data["minutely_15"]["time"]
    rain = data["minutely_15"]["precipitation"]
except Exception:
    sys.exit(1)

Danach wird berechnet, ob in den nächsten zwei Stunden mindestens 0,5 mm Regen fallen. Dazu werden alle Werte der Liste rain addiert und in der Variablen total gespeichert. Erreicht total den Schwellenwert nicht, wird das Skript wiederum mit dem Exit-Code 1 beendet, und die Regel löst nicht aus.

# 2 Entscheiden, Exit 1 bedeutet nichts tun
total = sum(x or 0 for x in rain)
if total < THRESHOLD_MM:
    sys.exit(1)

Anschließend wird der erste Zeitpunkt innerhalb der zwei Stunden ermittelt, zu dem laut Vorhersage Regen einsetzt. Dazu fasst die Funktion zip(times, rain) die Werte aus beiden Listen „positionsweise“ zu Paaren zusammen, jeweils eine Uhrzeit mit dem passenden Niederschlagswert. next(...) nimmt daraus den ersten Zeitpunkt, zu dem der Niederschlagswert größer als null ist, und speichert ihn in first. Danach wird berechnet, wie viele Minuten bis zu diesem Zeitpunkt vergehen. Liegt er bereits in der Vergangenheit, wird die Wartezeit auf null gesetzt.

# 3 Beginn des Regens und Wartezeit bestimmen
first = next((t for t, x in zip(times, rain) if (x or 0) > 0), times[0])
minutes = max(0, int((datetime.fromisoformat(first) - datetime.now()).total_seconds() // 60))

Im letzten Schritt gibt das Skript die Werte für die Mitteilung als Schlüssel-Wert-Paare aus, damit die Aktion „Show Notification“ sie verwenden kann.

# 4 Daten für die Aktion ausgeben
print(f"mm={total:.1f}")
print(f"start={first[11:16]}")
print(f"minutes={minutes}")

Diese Werte lassen sich in den Feldern „Title“ und „Body“ der Mitteilung als Platzhalter einsetzen, hier {{minutes}}, {{mm}} und {{start}}.

Sobald Regen vorhergesagt wird, erscheint eine Mitteilung wie diese.

Bei anhaltendem Regen kommt es auf den Schalter „Trigger on“ an.

Steht der Schalter auf „State Changes“, gibt es nur dann eine Meldung, wenn zum ersten Mal Regen innerhalb der nächsten zwei Stunden vorhergesagt wird. Jeder weitere Aufruf endet zwar weiterhin mit dem Exit-Code 0, führt aber nicht zu einer neuen Mitteilung. Erst wenn die Vorhersage keinen nennenswerten Regen mehr enthält oder der Dienst nicht erreichbar ist, endet das Skript wieder mit dem Exit-Code 1. Dadurch wird ein interner Merker zurückgesetzt, und beim nächsten Aufruf mit dem Code 0 erscheint wieder eine Mitteilung.

Steht der Schalter auf „Every Run“, erscheint bei jedem Aufruf, also alle zehn Minuten, eine neue Mitteilung mit aktualisierten Daten, solange Regen vorhergesagt wird. Erst wenn kein Regen mehr erwartet wird, bleiben die Mitteilungen aus. In beiden Fällen gilt das nur, wenn mindestens 0,5 mm Regen vorhergesagt werden.

Das ist eine einfache Lösung, die nur davor warnt, dass es irgendwann in den nächsten zwei Stunden regnen wird. Ein Hinweis, wann der Regen wieder aufhört, fehlt. Ihn zu ergänzen würde hier aber den Rahmen sprengen.

Zusammenfassend lassen sich mit einem Skript-Trigger eigene Ereignisse definieren, etwa um fehlende Sensoren des Systems abzufragen oder einen beliebigen externen Dienst einzubinden.

Regeln teilen

Regeln lassen sich mit anderen Crank-Nutzern teilen. Dazu klickt man oben rechts an der Regelbox auf das macOS-typische Teilen-Symbol. Dadurch wird ein Link in die Zwischenablage kopiert, der ungefähr so aussieht (hier die Regenwarnung als Beispiel):

https://crank.lowtechguys.com/rule/YnZ4bvEEAACvAwAA4Ah7IjMiOiJub3RpZmljYXRpb24iLCIxMDQAFeADXC91c3JcL2JpblwvcHl0aG9uMwAcQBp2QAgxgAk0MeALe3ttbX19IG1tIGVyd2FydGV0LCBhYiB7e3N0AA4AGsAsVWhyQCsy73NjcmlwdFRyaWdnZXJlZAhCRjDoUmVnZW4gaW4ANOdtaW51dGVzADZQCk0Iikg7NuAZaW1wb3J0IGpzb24sIHN5cywgdXJsbGliLnJlcXVlc3RcbmZyb20gZGEAgORpbWUgIDAoEOAYXG5cbkxBVCwgTE9OID0gNDkuNDAsIDguNjhcblRIUkVTSE9MRF9NTQAc6zAuNSAgICMgU3VtAEjqZGVyIG7DpGNocwCN6iAyIFN0dW5kZW4IUMAvVVJM4CAoZlwiaHR0cHM6XC9cL2FwaS5vcGVuLW1ldGVvLmNvbVwvdjFcL2ZvcmVjYXN0P2wBYOZ0dWRlPXsAj-Z9JmxvbmcoEOhPTn1cIlxuIBgByQ1cIiby52x5XzE1PXAAQORpcGl0EZ9oTyZoI1_0iOo4Juh6b25lPUV1cgCG5yUyRkJlcmwBvIixIinmIyAxIERhCMjkaG9sZQFI7mJlaSBqZWRlbSBGZWhsAOrlc3RpbGwBvkBfYkjmaOR0cnk6GJPkd2l0aDl09UAPLgjtQQooiH0sIOxvdXQ9NSkgYXMgcjowygmFybxhID3x6C5sb2FkKHIpGB0IM8ghcyA98cjNW1wi98ARXCJdEbqYLSJd5HJhaW44LPABOSHzEDXoZXhjZXB0IEUQBwAVIJICPecuZXhpdCgxIRXmMiBFbnRzAPCJFWlkQBxFASlBGGIAYut0IG5pY2h0cyB0dQkP5G90YWwAhetzdW0oeCBvciAwIAGLir0geAigAFLIJmlmIPKaWTwg9jh9_ugzIEJlZ2lubgJpkwlzIIJicyCLSiBXgIt6ZUFqYsmOaW1t5WZpcnN0AH8A2-R0KCh0EHyYf3Qs5HppcCgRUFiKLECJICCkwAUpID4ZouRzWzBdAHsZPwl85G1heCgDC4BSaW4rLktMLsBgaXNv5G1hdCgQd8tOKSAt9egubm93KCkpLhDp619zZWNvbmRzKCkgCwLkIDYwKSDcYm4062bDvHIgZGllIEFrCYjnIGF1c2dlYgjRiHhwcgNC5G1tPXsQTuU6LjFmfRKwMBwUSJCGPXvnWzExOjE2XTgi9SDObD898QAfDDlGM-U2MDAuMAzQNIDiIn0GAAAAAAAAAGJ2eCQ

Die Regel wird dabei nicht auf einem Server gespeichert. Sie steckt komplett im Link, und zwar komprimiert und Base64-kodiert, aber nicht verschlüsselt. Wer den Link hat, kann ihren Inhalt also lesen. Der Server dient offenbar nur als Brücke. Er ersetzt den Teil https://crank.lowtechguys.com/ durch crank://, sodass die Regel bei einem Aufruf sofort in Crank in einem Import-Fenster erscheint.

Vor dem Import sollte man unbedingt kontrollieren, was die Regel macht. Eine geteilte Regel kann Shell-Skripte auf dem Rechner ausführen. Dabei kann es je nach Sicherheitseinstellungen auch ohne Rückfrage geschehen. Alles, was in einer Regel steht, steckt auch im Link, etwa Pfade, Orte oder Zugangsdaten. Das sollte man vor dem Teilen bedenken.

Wer den Server umgehen möchte, kann den Link auch selbst bearbeiten und https://crank.lowtechguys.com/ durch crank:// ersetzen. Gibt man diese Adresse in einen Browser ein, wird die Regel genauso importiert.

Ich weiß nicht, warum die Entwickler diesen Weg gewählt haben, statt die Regel einfach als Datei zu speichern, die sich dann teilen ließe.

Fazit

Crank reiht sich in eine Reihe von Werkzeugen ein, die dabei helfen, bestimmte Abläufe zu automatisieren. Es besticht durch die einfache Umsetzung des Ansatzes Trigger → Bedingung → Aktion, durch die große Zahl an Triggern und durch die unterstützten Skriptsprachen. Für einfache Aktionen lassen sich Apple Kurzbefehle nutzen, zsh eignet sich für vorhandene Kommandozeilenwerkzeuge, Python für Webdienste und JSON-Verarbeitung und ein Swift-Skript glänzt bei Aktionen, die Zugriff auf macOS-Frameworks benötigen. Wer eine andere Sprache bevorzugt, kann sogar einen eigenen Interpreter einbinden.

Es gibt aber auch einige Kritikpunkte.

Schalter liegen oft weit von dem entfernt, was sie steuern. Der Schalter „Also run an action when the file is deleted“ steht unten in der Regel, die zugehörige Aktion erscheint aber im oberen Teil.
Bedingungen sind auf mehrere Stellen verteilt, nämlich auf die IF-Zeile, den „Watch Path“ und den Schalter „Conditions“.
Regeln lassen sich in der Liste nicht frei verschieben. Die Gruppen bieten zwar etwas Ordnung, ein freieres Sortieren wäre aber hilfreich.

Profile sind eine praktische Möglichkeit, Regeln je nach Arbeitskontext zusammenzustellen. Schade ist nur, dass sich Regeln per Kontextmenü zwischen Profilen verschieben, aber nicht kopieren lassen.

Für einfache Anwendungen ist das Programm einigermaßen intuitiv zu bedienen. Es gibt aber auch komplexere Konzepte, die sich nicht durch bloßes Hinsehen erschließen, etwa „State Changes“ gegenüber „Every Run“ oder „Throttle“ gegenüber „Debounce“. Hier wäre mehr Dokumentation hilfreich, auch wenn der Slogan „no manual required“ lautet.

Wer einen einfachen Weg sucht, Skripte abhängig von Systemereignissen oder zeitgesteuert auszuführen, kann mit Crank sehr schnell zum Ziel kommen. Allerdings ist ein Mindestmaß an Programmierkenntnissen notwendig. Selbst wenn nur fertige Regeln aus dem Internet oder eine KI für die Erstellung genutzt werden, sollte man so viel Wissen mitbringen, dass man zumindest grob versteht, was das Skript macht.

dit und dat