Aktueller Sachstand:
Ich habe 2 AppleSkript Programme.
Das Erste sucht in meinem DownloadOrdner nach einem Muster Konto*.pdf. Dann werden diese Dateinamen (Format: Konto_[Kontonummer]-Auszug[_Jahr_LaufendeNummer].pdf) ausgelesen und an der 2. Stelle ausgewertet. Dann werden die Dateien in den Ordner $PfadBeliebig/[Kontonummer]_beliebigeErgänzung kopiert
Das Zweite durchsucht nun alle Ordner in $PfadBeliebig und benennt alle Dateien mit dem Muster Konto_[Kontonummer]-Auszug[_Jahr_LaufendeNummer].pdf
in
Kontoauszug_[Kontonummer][_Jahr_LaufendeNummer].pdf
um.

Leider funktionieren die AppleSkripte seit Ventura oder der Version davor nur noch, wenn ich sie in AppleSkript öffne und dann dort starte.

Nun meine Frage. Kann das auch Automator?
Geschafft habe ich bisher den Ordner Download zu durchsuchen, Die richtigen Dateien zu finden und an eine beliebige Stelle hin zu bewegen.
Was ich nicht geschafft habe: Den Zielordner anhand der Dateinamen festzulegen und die richtigen Kontoauszüge eines Kontos in den richtigen KontoOrdner zu verschieben.
Geht das überhaupt?

Ich weiß nicht, wie versiert du im Skripten bist

Aber ein normales Shellskript sollte doch einfache moves nach folgendem Muster erledigen können.

Der jeweilige Befehl für die Kontonummern:
mv *KONTONUMMER*.pdf /pfad/zum/zielverzeichnis/KONTONUMMER/

Soll jetzt nur als Anregung dienen.

Danke das sollte ich hin bekommen.
Ich würde aber sagen, dass meine bisherige „Anforderung“ dann aber doch etwas komplexer ist.
Ich habe es jetzt mal mit einem Kurzbefehl probiert und umgesetzt. Da kann man auch AppleSkript einbinden und das hat auch funktioniert. Der Automator kann wohl solch komplexe Dinge wie „suche mit etwas bestimmtes und lege es dann in Abhängigkeit davon in ein bestimmtes Verzeichnis“ nicht. Eventuell müsste man dann je Konto einen eigenen Automator anlegen UND wenn der Automator nichts findet, dann meldet er auch noch einen Fehler, den man nicht abschalten kann 🙈 und er dann einfach die Bearbeitung einstellt.

Laß das mit dem Automator und versuch es mit einem Shellskript - damit kannst du so ziemlich alles machen (außer Kaffee kochen).
AppleScript wurde von Apple schon vor längerem „entsorgt“ da war damit zu rechnen, daß das irgendwann nicht mehr funktioniert.
Zu Shellskripten gibt es hier sicher genügend kompetente Menschen, die dir da unter die Arme greifen können (ich leider nicht).

Könnte es sein, dass Du den Skripten in Systemeinstellungen → Sicherheit → Festplattenvollzugriff (Ventura-Pendant weiß ich nicht) einfach nicht die notwendige Erlaubnis erteilt hast?
Apple pflegt AppleScript nicht gerade besonders liebevoll, aber es ist nicht abgekündigt.

Shellskripte sind sicher sinnvoller, wenn es um Dateioperationen oder allgemein um alles geht, was auf der Unix-Ebene lösbar ist. Aber Apps kannst Du eben nunmal nur über AppleScript oder Javascript for Automation ansprechen.

In einem früheren Thread habe ich etwas ausführlicher erläutert, was man wann verwenden sollte (Beitrag von 17.11.2022 um 04:58 Uhr).

Ich habe vor Kurzem etwas ganz Ähnliches gemacht:

1- Verschiedene PDFs aus regelmäßig eingehenden Mail werden in einen (vorläufigen) Folder extrahiert
2- Von dort aus werden die PDFs in ein Jahresarchiv verschoben und ...
3- ... abhängig vom Namen und Inhalt klassifiziert. Aus der gewonnenen Info werden Symlinks zu den archivierten Files mit sprechenden Namen erstellt.

Realisiert habe ich das mit

zu 1- Einer AppleSkript-Regel in Mail.
Obskure, umständliche Sprache, funktioniert so-la-la und nur so vielleicht.

Wirklich zufrieden bin ich damit nicht, habe aber bisher keine gute Alternative. Suche noch.

zu 2- Einem Shell-Skript, als automatische Ordner-Aktion ins System eingeklinkt.
Nichts Besonderes, mv, log und sowas. Funktioniert zufriedenstellend.

zu 3- Einem selbstgeschriebenen, "echten" Programm zur weiteren Analyse und Klassifizierung der PDFs. Heute nennt man sowas "Äpp".

Geschrieben in - ihr werdet lachen: Aus alter Gewohnheit mit Visual Studio in C#.
Klappt 1A-mit-Sternchen !

Ich fand es faszinierend, wie problemlos heutzutage Libraries und Funktionen aus der Windows-Welt auf Mac -einfach so- funktioneren. Kann man drauf aufbauen.

Für solche Aufgaben eignet sich Hazel auch.

Seit Jahren verwende ich es um automatisches Verschieben, Kopieren, Umbenennen, etc. zu machen. Für Bilder, downloads, kontoauszüge, serien, etc.

42 $ finde ich schon sehr viel.... gibt es noch andere Software die das auch alles kann?

Du kannst Dir FolderTidy anschauen, das bietet weniger Automation, ist aber auch viel günstiger.
In Devonthink kannst Du solche Aktionen auch per Regeln durchführen. Das macht aber nur Sinn, wenn Du Devonthink ohnehin benutzen möchtest, da es teurer als Hazel ist.
Ich benutze beides, Hazel und Devonthink.

Was den Teil des Umbenennens (nicht des Verschiebens in andere Verzeichnisse) betrifft, ist A Better Finder Rename (oder kurz "ABFR") kaum zu schlagen: https://www.publicspace.net/ABetterFinderRename/ . ABFR ist schnell, modern programmiert, funktioniert zuverlässig und ist sehr mächtig und intuitiv zu bedienen. Deine Aufgabenbeschreibung oben ist nicht ganz eindeutig genug, evt. ist das Verschieben in ein anderes Verzeichnis mehr eine Art Notlösung, um die Umbenennung, um die es eigentlich geht, in zwei Schritten zu realisieren. Damit Du zumindest einen Eindruck von ABFR bekommst, hier eine Teillösung Deines zweiten Skripts in ABFR:

Es lassen sich natürlich mehrere solcher Schritte kombinieren. Dieser eine Schritt verschiebt z.B. die Kontonummer an den Anfang des Dateinamens. Man kann auch den Dateipfad einer Datei zu deren Namensbestandteil machen.

Danke marm, leider ist da wohl der entwicklersupport sehr lausig, aber grundsätzlich suche ich sowas... hat da jemand anders noch eine empfehlung? Devonthink nutze ich nicht und auch zu teuer.. um einmal in der etwas zu sortieren...

Du weißt, dass man statt AppleScript auch Javascript for Automation verwenden kann?

Ob das in Deinem Fall besser funktioniert, kann ich nicht sagen, da ich nicht weiß, ob das so-la-la am Skript oder an Mail liegt.
Auf Unix-Ebene den Postfix-Mailserver von macOS konfigurieren und mit fetchmail und procmail ergänzen ist eine 100% zuverlässige, leistungsfähige Lösung, erfordert aber natürlich ziemliches Unix-Wissen.
Ich weine eher, weil – nicht in Deinem Fall, aber generell – dadurch so viele mediokre Software auf den Mac gelangt, die nicht wirklich nativ ist.

Aber mal doof gefragt: Wie geht das denn? Gibt es Visual Studio auf dem Mac oder kannst Du auf dem PC auf dem Mac lauffähige Programme erstellen?

Hi Weia, ich erlaube mir mal die Frage zu beantworten: Visual Studio gibt es auch für den Mac. Es lassen sich damit auch native Cocoa-Programme erzeugen, nur nicht mit Objective-C oder Swift (meines Wissens), sondern z.B. mit C#:

Ah, danke!
Nah, eben nicht. Das ist wieder Cross-Platform (Xamarin) und damit eben nicht nativ.

Man kann damit nativ oder nicht nativ programmieren. Also für mich ist es nativ, wenn gegen das Cocoa-Framework programmiert wird.

Die Javascript-Option ist mir grundsätzlich bekannt, allerdings kann ich als Mail-Regel zunächst nur Applescript definieren. Eventuelle Umwege habe ich noch nicht ausprobiert.
Den meisten Zirkus macht allerdings Mail selbst. Wird allerorts auch so berichtet.
So in der Art. Ein Client, der nur auf diese Sorte Mail anspringt und sie von vorneherein wegarbeitet.
Gibt es und geht beides, in beide Richtungen. Das war ja die Überraschung.

Konkret:

Ich schreibe wahlweise auf Mac oder Windows ein Programm unter Verwendung von Windows-APIs (".NET") und kompiliere. Das Ergebnis ist ein Ordner mit Dateien drin, sozusagen ein App-Bundle. Dieses Bundle ist ohne weitere Anpassung lauffähig auf Mac und Windows.
Wenn man will, kann man das auch in ein echtes App-Bundle verpacken, sie nennen das Publish.

Neben diesem Programm habe ich noch ein komplexeres, das ich komplett auf Mac entwickelt und zum Schluss auf Windows kopiert und als Hintergrund-Systemdienst eingerichtet habe. Funktioniert einwandfrei.

Am Verblüffensten fand ich, dass man allerlei Windows-Libraries von Drittanbietern ohne Neu-Kompilierung direkt dazuladen und verwenden kann.

----
PS: Alles Programme für den Hausgebrauch. Um Haken und Ösen rund um Veröffentlichung etc. habe ich mich nicht gekümmert.

Nein, ist es eben nicht. gegen das Cocoa-Framework ist eine wohl unfreiwillig gute Beschreibung des Problems.

Cross-Platform-Entwicklungsumgebungen können, um Cross-Platform zu sein, prinzipiell nur mit einer eigenen Meta-Sprache arbeiten, die die GUI beschreibt, also wo welche Buttons im Fenster sitzen usw. Ganz am Schluss bei der Kompilation wird das dann in die entsprechenden Cocoa-Elemente bzw. die Windows-Pendants übersetzt. Damit fallen aber prinzipbedingt alle Möglichkeiten und Feinheiten, die nur eine Plattform bietet, unter den Tisch. Ich würde mich z.B. sehr wundern, wenn Autolayout, das intelligente Berechnen der Position einzelner GUI-Elemente je nach Länge des Textes in der vom Nutzer gewählten Lokalisierung, möglich wäre.

Native Cocoa-Apps sind nur mit Objective-C und Swift möglich; andere Schnittstellen gibt es in Cocoa nicht. Von C# aus muss immer erst noch übersetzt werden und da gibt es immer Einschränkungen.

Ja, dafür ist das natürlich vollkommen legitim.

Zum Ausgangsthema hier ein Artikel von EclecticLight zu Folder Actions, Hazel und fswatch

Ich weiß nicht genau, was Du da differenzieren willst, aber der GUI-Code, der laufenden App ist von Apple und nicht von Xamarin oder Microsoft.

Mangels Ahnung will mich jetzt wegen der GUI-Frage nicht so aus dem Fenster lehnen, meines Wissens will aber Swift auch in der Cross-Platform-Liga (hier: Android) mitspielen. Scheint mir so ein allgemeiner Trend zu sein..

Ja, aber wurde durch eine Übersetzung erzeugt; C# kann Cocoa nicht ansteuern.

Und bei dieser Übersetzung gehen eben manche Dinge schief oder verloren; z.B. wird Button zwar von Cocoa gezeichnet, sitzt aber nicht ganz genau an der richtigen Stelle usw. Und Sachen, die Cocoa könnte, werden nicht ausgenutzt, weil Xamarin sie eben nicht kann.

Ich kann Dir, abgesehen von Super-Simpel-Apps mit 1 Button, nach ein paar Minuten praktisch immer sagen, ob eine Cocoa-App nativ oder cross-platform erzeugt wurde, und habe mich so gut wie noch nie getäuscht.

Ist in dem Zusammenhang hier jetzt aber wirklich egal.

Ja, leider. Es lebe das kleinste gemeinsame Vielfache …

Swift ist sowieso das, was ich Tim Cook am übelsten von allem nehme, was unter seiner Ägide geschah.

Ich programmiere zwar, bin aber eher ein Anwender der Sprachen und Frameworks, als ein Experte darin, wie die Programmierwerkzeuge gebaut werden. Von einer "Übersetzung" würde ich jedoch nicht sprechen. Der Fachbegriff dafür, wie das technisch umgesetzt ist, ist - so weit ich weiß "Bridging".

Am Namen hängt aber nichts. Wenn eine Sprache (C#) in eine andere (Objective-C oder Swift) transformiert wird (und das muss sie, da Cocoa C# nicht versteht), halte ich ich Übersetzung für eine treffliche Bezeichnung.

Bridging ist wieder etwas anderes. Da greifst Du auf denselben Code mit verschiedenen Sprachen zu. Z.B. kannst Du etliche Foundation-Objekte auch mit C adressieren, weil aus Assembler-Perspektive die Daten in denselben Speicherzellen sitzen, egal, ob sie als Objekt oder als C-Funktion verstanden werden.

Meines Wissens stellt der Brückencode die Verbindung zu dem nativen Framework - hier Cocoa - her. Es wird doch keine Sprache in eine andere übersetzt, sondern nur Klassen verwendet die in einer anderen Sprache geschrieben wurden. Wie gesagt, der GUI-Code, der dann letztendlich läuft ist der native Cocoa-Code (bzw. dessen kompilierte Form).

Du kannst aber keine Klasse, die in einer Sprache geschrieben wurde, in einer anderen verwenden. Eine Klasse in Objective-C ist etwas ziemlich anderes als eine Klasse in C#. Daher musst du die Sprache übersetzen.
Das stimmt natürlich. Aber das heißt ja nicht, dass man nicht gute und weniger gute Programme in Cocoa schreiben kann. Und gute Cocoa-Programmierer schreiben eben guten Cocoa-Code und Xamarin schreibt bei der unumgänglichen Übersetzung weniger guten.

Ich weiß, dass Du Swift nicht sonderlich magst und vermutlich würdest Du diese Formulierung noch für untertrieben halten, und nur Objective-C als die einzig wahre Sprache bezeichnen um Cocoa zu verwenden Tatsache ist aber auch, dass sich mit Swift und C# native Cocoa-Programme erstellen lassen. Da die Konzepte von C# und Swift sehr ähnlich sind, besteht so gesehen eigentlich kein Grund, warum C# Cocoa nicht ähnlich gut verwenden können sollte, wie Swift. Visual Studio verwendet bei Cocoa-Projekten auch Storyboards in Xcode und erzeugt beispielsweise automatisch den View Controller in Xcode. Hier eine von Visual Studio in Xcode generierte Objective-C- Datei. Gut zu sehen sind die Cocoa-Referenzen:

Nein, mit C# geht das nicht, nur mit Swift.
Die Ähnlichkeit der Sprachen hat damit doch nichts zu tun. Der Grund ist schlicht und ergreifend, dass Cocoa eine Objective-C-API und eine Swift-API hat, aber keine C#-API. Alles, was Du in C# schreibst, muss daher in einem Zwischenschritt erst nach entweder Objective-C oder Swift übersetzt werden. Ich weiß nicht, was daran so schwer zu verstehen ist.
Ja, klar, das ist eine Objective-C-Datei.

Aber jetzt gibt es doch nur zwei Möglichkeiten: Entweder, Du bearbeitest diese Datei direkt, dann programmierst Du aber in Objective-C und nicht in C#. Oder Du programmierst in C#, dann muss das aber erst von Visual Studio in diese Datei übersetzt werden. Der Kommentar selbst spricht von transfer und synchronize, beides Umschreibungen des Übersetzungsvorgangs.

Wir sind jetzt aber heftig off-topic.

kostenlose Hazel Alternativen:

• organize
• Maid

Ja, wir sind heftig off-topic. Es ging bei unserem ausgedehntem Nebenthema eingangs um VisualStudio. Wenn ich damit in C# native Cocoa-Oberflächen erstelle, dann programmiere ich komplett in C#, ohne mit Objective-C in Berührung zu kommen, weil VisualStudio das übernimmt. Die Oberfläche wird dabei genauso im Xcode InterfaceBuilder arrangiert, wie bei Objective-C oder Swift-Programmierung in Xcode. Wie das letztendlich technisch gelöst wird, finde ich zwar interessant, aber für die Programmierung praktisch nicht relevant. Das Ergebnis sind native Cocoa-GUIs.

Aber das geht eben nicht. Ich geb’s auf.
Wir haben bislang aber nicht über native GUIs gesprochen, sondern über native Apps. Was nützt Dir eine Cocoa-GUI, wenn die App nicht nativ ist und Du all die Cocoa-Vorteile für GUIs (Bindings, …) nicht nutzen kannst?

Wir hatten anfangs über Visual Studio für den Mac gesprochen. Es tut mir leid, wenn Du aufgibst, aber Du täuscht Dich einfach. Wieso sollten denn keine Bindings unterstützt werden? Das MVC-Pattern wird genauso unterstützt, wie direkt mit Objective-C. Ich vermute, das wird Dich auch nicht überzeugen, aber hier die Aussage von Microsoft zu dem Thema:Quelle:

Weil es dazu bestimmter Vorkehrungen in der Programmiersprache bedarf.
Erstaunlich, dann hat Xamarin hier entsprechende Vorkehrungen getroffen und ich habe mich in diesem Punkt geirrt.

Hmm, C# in seiner .Net-Welt unterstützt ja auf jeden Fall in ausreichendem Maße die Prinzipien bezüglich Bindings wie Objective-C. Objective-C hat eine eigene kleine Laufzeitumgebung . Die Brücke zwischen der .Net-Welt und der Objective-C-Welt schafft Xamarin dann zur Laufzeit: Quelle: https://learn.microsoft.com/en-us/xamarin/mac/internals/how-it-works

Eigentlich hatte ich Visual Studio bisher auch gut benutzen können, ohne den ganzen Xamarin-Zauber zu verstehen. Durch die Diskussion mit Dir verstehe ich es jetzt wenigstens ein bißchen. So, jetzt höre ich auch auf damit, diesen Thread länger zu kapern.