Ich arbeite hier mit dem Python-Programm icloudpd und erzeuge mir damit eine vollständige Kopie der iCloud-PhotoLibrary auf einer externen Platte. Interaktiv arbeitet das Programm genau wie erwartet.

Auf der Kiste (MacOS 13.4.1c) befindet sich die Python-Version 3.9.6, die im Rahmen von XCode mitgekommen war.

Um jetzt den Programmstart von icloudpd zu automatisieren, kam ich auf die Idee, es über Kurzbefehle zu versuchen. Eigentlich nicht weiter aufregend:

• 2 Argumente setzen, 1 Passwort abfragen
• die Argumente an eine Shell-Skript weitergeben
• das Shell-Skript gibt die Argumente seinerseits an icloudpd weiter

Sollte eigentlich problemlos klappen.

Interaktiv starte ich das Programm z.B. so

Wenn ich das Gleiche in einen einfachen Kurzbefehl verpacke, schmiert mir Python regelmäßig mit einem Stacktrace ab. Den Trace interpretiere ich so, dass die übergebenen Argumente irgendwo unterwegs verloren gegangen sind.


Wenn ich zur Kontrolle das Shell-Skript mal mit echo's garniere, sieht man klar, das die Kurzbefehle-App die Argumente korrekt an das Skript übergeben hat.
Ich habe schon einige Varianten durchgetestet, unter anderem auch den Direktstart des Python-Skripts ganz ohne Shell dazwischen. Das Ergebnis bleibt immer gleich.


Was mich zu der finalen Frage bringt:

• Was ist an Kurzbefehlen so anders, dass ein ansonsten funktionierendes Python-Programm innerhalb von Kurzbefehlen immer abschmiert ?

Übergebe die Variablen versuchsweise nicht als $1, $2 sondern als Variablen aus Kurzbefehle. So ungefähr wie hier mit "Text" und "Auswahl". Hier ein Ruby-Skript-Anfang:


Warum startest du nicht direkt Python, sondern ein Shell-Skript? Bei 'Shell' kannst Du Python auswählen. Ich nehme mal an, dass das Python-Skript so nicht weiß, dass vorher "cd ~/Library/Python/3.9/bin" durchgeführt wurde.
Ich habe schon mehrere Python- und Ruby-Skripte über Kurzbefehle zum Laufen gebracht.

Da war ich schon und es macht keinen Unterschied.

Mit einfacheren Argumenten (hier: --dry-run --help) funktioniert es genau so, wie ich das will. Irgendwie kommt bloß der Inhalt der Optionen nicht durch

ok, kannst Du dein Shell-Skript in eine Kommando-Zeile packen? Ungefähr so:
Weil das Python-Skript sonst nicht weiß, dass das Verzeichnis gewechselt hat. Das Problem hatte ich anfänglich zumindest ... Und wie gesagt, kannst du die Variablen auch von Kurzbefehle direkt nutzen statt $x.

Was passiert, wenn Du statt ~ explizit den Pfadnamen angibst?

Ääähh – warum nicht einfach

• mit und ohne Shell
• mit und ohne cd - eine Zeile
• mit und ohne ~

Da waren wir überall schon.

Es sieht stark so aus, als ob das Programm die übergebenen Argumente nicht oder falsch auseinanderfieselt.
Ich hatte ihn zwischenzeitlich auch mal so weit, dass er wenigstens über den Path herumnölt - allerdings grundlos.

Ich neige jetzt dazu, das Kurzbefehle-Experiment zu beenden und andere Wege zu beschreiten. Gibt ja noch Optionen.

Und Variablen einsetzen hast Du auch probiert statt Argumente?

Du vielleicht, wir nicht. Nirgendwo steht, dass Du schon einmal probiert hattest, ~ zu eliminieren.

Deine Problembeschreibung klingt einfach sehr nach fehlendem Environment. sh statt zsh als Shell zu nutzen, wäre vielleicht auch noch einen Versuch wert.

Zwischenstand jetzt:

• Der DAE (Dümmste Anzunehmenste Einzeiler) ohne jedes cd oder ~ etc. funktioniert interaktiv einwandfrei.
• In Kurzbefehle crasht Python, egal welche Shell man angibt
• Übergabe der Argumente als eingesetzte Variable macht (erwartungsgemäß) keinen Unterschied.
• Wenn ich das DAE-Skript zum LaunchAgent umbaue, gibt's Hinweise auf "no permission" mit dem ansonsten gleichen Python-Crash.

Die aktuelle Hypothese geht dahin, dass sowohl in Kurzbefehle als auch als LaunchAgent dem Python-Skript irgendwelche Rechte auf die AppleID/iCloud verweigert werden.
Den Rest des Tages habe ich leider keine Zeit mehr, das weiter zu verfolgen.

Warum startest du das Skript nicht mit python3 <pfad>/icloudpd <argumente>?

Damit macOS es überhaupt als Python Script erkennt wird es ein hashbang haben müssen. Es ist gut möglich, dass der hashbang dann in der Shell deiner Wahl mit deinem Environment ausgeführt wird und dann eine Shell gemäß des hashbangs öffnet, in dem das Environment fehlt. Außerdem muss das Python Skript selbst dann nicht ausführbar sein.
Diesbezüglich könnte sich der Aufruf im Terminal von einem Aufruf aus Kurzbefehle unterscheiden.

Wenn du Python mit dem Namen/Pfad deines Skripts öffnest, klappt es vielleicht besser. Das ist jetzt aber einfach nur eine reine Vermutung ohne irgendwas selbst geprüft zu haben.

Oh, und bist du dir sicher, dass argv eine Liste ist und nicht ein einzelner String?

Ihr werdet lachen (oder weinen):
So habe ich das Ganze jetzt ans Laufen bekommen.



iCloudPD.command :


Das Kurzbefehl-Skript habe ich in eine .app konvertiert und kann die ganz wunschgemäß als unsichtbarer Dauerläufer beim Login starten. Bisschen clumsy, aber für's Erste OK.

So ganz zufrieden bin ich trotzdem nicht und es bleiben offene Fragen, was da eigentlich schiefläuft:

Es fiel mir auf, dass das Paket nur in x86-Version existiert und unter Rosetta läuft. Keine Ahnung, ob das eine Bedeutung hat und leider kenn ich nix von Python und kann das Ganze nicht neu kompilieren.

Auf der Kiste lungern auch noch ein paar andere Python-Installationen rum, insbes. von Homebrew und MacPorts. Anscheinend bringt ja jedes zweite Paket irgendwelche Python-Fragmente mit. Gefällt mir eigentlich gar nicht und auch da habe ich keine Ahnung, ob das irgendwas ausmacht.

Und wenn das alles großer Murks ist, dann habe ich zumindest etwas über Kurzbefehle gelernt ...