START > APPLESCRIPT > Crashkurs AS > [1] Grundlagen, Skripteditor, Standard-Handler

[1] Grundlagen, Skripteditor, Standard-Handler

Was ist AppleScript?

AppleScript ist, wie der Name schon sagt, eine Script-Sprache, die bereits in den späten 80er Jahren von Apple entwickelt wurde. Grundgedanke bei der Entwicklung war wohl, eine leicht erlernbare Programmiersprache für jedermann auf dem Mac zu schaffen, mit der sich Aufgaben einfach automatisieren lassen. Dabei wurde versucht, die Sprache so nah wie möglich am normalen menschlichen Sprachgebrauch anzulehnen.

Zeitweise gab es neben der englische sogar lokalisierte AppleScript-Versionenn (Französisch und Italienisch glaube ich mal gelesen zu haben). Diese wurden aber aufgrund des hohen Entwicklungs-Aufwands und der Fehleranfälligkeit relativ rasch wieder eingestellt, während AppleScript bis heute weiterentwickelt wurde und eigentlich zu einer brauchbaren Programmiersprache mit vielen neuen Möglichkeiten (gerade unter OS X) zur Automatisierung herangereift ist.

Die besondere Stärke von AppleScript liegt darin, Aufgaben im Zusammenspiel mit verschiedensten Programmen zu realisieren und automatisch (von AS gesteuert) ablaufen zu lassen.

Für wen/was ist AppleScript geeignet?

Wenngleich es heute mittels XCode und AppleScript-Studio (Developer-Tools von Apple) mittlerweile möglich ist, komplette Applikationen in AppleScript zu realisieren, inklusive eigenem User-Interface und allem, was dazu gehört, ist AS weniger dafür geeignet, vollständige Programme zu schreiben, obwohl auch hier, wie gesagt, einiges möglich ist. Hierfür gibt es aber durchaus besser geeignete Programmiersprachen.

Vielmehr liegt der Schwerpunkt von AppleScript bis heute auf Automatisierungs-Aufgaben, auch wenn es hierfür wiederum auch den Automator unter Mac OS X gibt, bei dem man aber sehr schnell an Grenzen stößt.

Der Befehls-Umfang von AppleScript an sich ist dabei von Haus aus gar nicht sooo riesig und recht überschaubar. Es können aber von jedem Software-Entwickler Befehle für AppleScript zur Verfügung gestellt werden, mit denen sich ihre Programm per AppleScript ansprechen und steuern lassen. Der Umfang und die Gestaltung dieser Programm-bezogenen Befehle ist ebenso reichhaltig wie unterschiedlich.

Es lassen sich aber gerade aufgrund dieser Schnittstellen zu AppleScript die verschiedensten Aufgaben automatisieren, nicht zuletzt durch die eigens von Apple zur Verfügung gestellten Programme wie iCal, Mail, iTunes, ...

Eine wichtige Rolle spielen hierbei die im Hintergrund ablaufenden sogenannten AppleEvents, über die die Programme untereinander kommunizieren können.

Hinzu gesellt sich zusätzlich noch die Möglichkeit, shell-Befehle per AppleScript aufzurufen, und damit wiederum shell-scripts, perl, ... und selbst Javascript-Code lässt sich in einigen Programm (Safari, Acrobat, ...) direkt aus AppleScript ausführen. Mit all diesen zusätzlichen Optionen sind die Möglichkeiten dann nahezu unbegrenzt...

Ist AppleScript schwierig?

Wer sich einigermaßen im Englischen zurecht findet, und mal ein paar Beispiel-Scripts angeguckt hat, der könnte zu dem Schluss kommen, daß AppleScript ja nun wirklich einfach ist. Dem will ich auch nicht zwangsläufig widersprechen. Doch seid gewarnt: Es ist um vieles einfacher, ein AppleScript zu lesen als eines zu schreiben, das auch funktioniert. Manchmal hapert es an einfachen Formulierungs-Fehlern, da man dazu neigt, einfach mit seinem Script-Editor englisch zu reden. Aber AppleScript ist eine Zicke!

Die Schwierigkeiten können also deutlich höher ausfallen, als man anfänglich meint, und es gibt viel «Trial and Error», zumal Dokumentationen (insbesondere zur Steuerung von bestimmten Programmen) auch nicht so weit verbreitet sind. Aber keine Angst: Es gibt auch immer wieder kleinere und größere Erfolgserlebnisse! Und es ist einfach toll, seinen eigenen AppleScripts bei der Arbeit zuzusehen, oder anderen damit eine Freude zu machen. Und noch eine Warnung: AS macht süchtig!

Was brauche ich?

Was auf jeden Fall gebraucht wird, ist ein Mac! Und das Erfreuliche: das war's auch schon. Hast Du einen Mac, dann ist alles da, um AppleScripts zu generieren, und das war schon fast immer so. Um ein AppleScript zu schreiben und anschließend zu compilieren (zu übersetzen und lauffähig abzuspeichern) braucht man einen Editor, den Apple auch gleich mitliefert: Unter Mac OS 9.x in Programme/Apple Extras/AppleScript/Skripteditor zu finden, unter OSX unter Programme/AppleScript/Skripteditor.app. Es gibt auch noch andere Editoren, aber die ignorieren wir jetzt mal, da man mit dem hauseigenen Skripteditor mittlerweile sehr gut bedient ist.

Wie fange ich an?

Man kann viel über AppleScript lesen, aber um es wirklich zu lernen, hilft eigentlich nur, einfach mal ein Script zu schreiben. Und schliesslich kommen ja die meisten genau so zu AppleScript: Es gibt eine immer wiederkehrende Aufgabe, die man doch vielleicht automatisch erledigen lassen könnte. «Ich hab da doch mal was gehört/gelesen. AppleScript oder so!?».
Deshalb jetzt nur noch einen kurzen Blick auf den Skripteditor und seine Funktionen, und dann nichts wie ran an das erste Script ...

Der Skripteditor

Schauen wir uns zunächst einmal das wichtigste Werkzeug zur Erstellung von AppleScripts an: Den Skripteditor.

Funktionsverzeichnis

Eine der wichtigen Funktionen des Skripteditors, die sich einem Anfänger nicht gleich erschliessen, ist die Möglichkeit, die Funktionsverzeichnisse von skriptfähigen Programmen einzusehen. In diesen Funktionsverzeichnissen steht, welche Befehle, Klassen und Objekte in den einzelnen Programmen überhaupt zur Verfügung stehen.

Dies geschieht entweder über das Menü «Ablage > Funktionsverzeichnis öffnen...», in dem anschliessend das gewünschte Programm auswählt wird.

Oder über die zweite, etwas elegantere Methode: die Bibliothek-Palette (links dargestellt), die man über das Menü «Fenster > Bibliothek» bzw. über die Tastenkombination ⇧⌘L aufruft.

In dieser Bibliothek findet man bereits viele der scriptfähigen Programme von Apple vor. Weitere Programme lassen sich der Palette über den Plus-Button oder durch Hineinziehen des Programmsymbols hinzufügen, so dass auf das Funktionsverzeichnis dieser Programme künftig jederzeit schnell zugegriffen werden kann.

So findet man hier z.B. auch die StandardAdditions, die die Standard-AppleScript-Befehle bereitstellt. (Diese lassen sich ohne Aufruf eines tell-Blocks verwenden, doch dazu später mehr...)

Zwei weitere wichtige Funktionsverzeichnisse, die im folgenden noch häufig Verwendung finden werden, sind der «Finder» und die «System Events». Es kann nicht schaden, sich in diesen 3 wichtigen Bibliotheken einmal umzuschauen. So bekommt man einen ersten Eindruck davon, «was so gehen könnte».

An den Grundeinstellungen des Skripteditors muss zunächst nichts geändert werden. Die sind ganz sinnvoll eingestellt und fürs Erste okay so wie sie sind.



Sinn macht es aber, über das Menü «Darstellung > Steuerung einblenden» die Steuerungsleiste einzublenden, die dann unter den Menüleisten-Symbolen des Script-Fensters erscheint.

Editor-Menu 2

Damit können, wenn längere Scripts verfasst wurden, bequem und gezielt einzelne Scriptteile angesteuert werden. Auch dazu später mehr.

Das erste Script

So, nun wird's Zeit für's erste Script, um erste AppleScript-Grundlagen besprechen zu können. Es kommt das wohl kürzeste Skript wo geht. Ich kann euch dieses «Pisch-Skript» leider nicht ersparen, da es ideal ist, um zunächst einmal die Speicher-Optionen des Skripteditors zu besprechen, bevor wir etwas mehr Gas geben können, und uns den ersten Befehlen zuwenden:

beep

Was macht dieser einfache Dreizeiler? Er gibt einmal den System-Klang wieder. Der einfache Befehl beep kann also dafür genutzt werden, um den Warnton auszugeben. «Aber wieso denn Dreizeiler? Ist der Autor dieses Tutorials besoffen, oder völlig inkompetent, oder war das nur ein peinlicher Vertipper? Ich sehe jedenfalls nur eine Zeile!», werdet ihr jetzt vielleicht denken. Und da wären wir schon beim nächsten Thema, den Standard-Event-Handlern...

Die Standard-Event-Handler

on run-Handler

Das hört sich jetzt nach einem heftigen Sprung an (ist es auch), aber wir müssen das jetzt klären, da diese Handler mit den Speicher-Optionen des Skripteditors Hand-in-Hand zusammenspielen. Da müssen wir also jetzt schnell mal durch.

So, also mal ganz langsam zum mitschreiben: Das obige Skript ist in Wirklichkeit ein Dreizeiler, weil prinzipiell noch zwei Zeilen vom Skripteditor hinzu «gedacht» werden. Eigentlich müsste das Skript nämlich so aussehen:

on run
   beep
end run
 Im Scripteditor öffnen

Und damit wären wir schon beim ersten von AppleScript bereitgehaltenen Event-Handler. Ein Event-Handler wird immer mit on handlername eingeschaltet und muss mit end handlername beendet werden.
Aber was soll dieser on run-Handler nun? Alles, was zwischen diesem Handler an Code notiert wird, wird ausgeführt, wenn man das Skript als Programm speichert und dann per Doppelklick startet, oder im Finder markiert und per «Öffnen» (⌘O) startet, oder aber wenn man im Skripteditor auf den «Ausführen»-Button klickt, also immer dann, wenn es «läuft» (run).

Jetzt könnte man denken: «Ist doch logo, dass das, was ich in mein Skript schreibe, auch ausgeführt werden soll. Wozu denn noch extra angegeben?». Genau, kann ich da nur sagen, und deshalb kann man diese Zeilen auch weglassen. Aber: Es gibt noch mehr Event-Handler, die man definieren kann. Und dann muss man unterscheiden, wann welcher Code ausgeführt wird.

on open-Handler

Dazu nehmen wir uns mal den nächsten Event-Handler vor. Dann wird die Sache schon klarer:

on run
   beep 1
end run

on open
   beep 5
end open
 Im Scripteditor öffnen

Öffne dieses Script mal im Scripteditor (einfach auf den Link direkt unter dem Script klicken), und speichere es als Programm (ohne Startdialog) auf dem Desktop ab.

Editor-SaveDialog

Anschließend starte das gerade gesicherte Programm mal per Doppelklick. Es sollte der Systemton einmal abgespielt werden. Mehr soll's ja auch nicht tun, wenn's gestartet wird (on run).

Und nun droppe mal eine Datei auf das Skript-Programm. Der Ton sollte jetzt 5mal abgespielt werden. Das heisst, der on open-Handler reagiert also auf ein anderes Ereignis (Event), als der on run-Handler. Alles was zwischen ihm notiert wird, wird ausgeführt, wenn Dateien, Ordner oder Programme auf das AppleScript-Programm «gedroppt» werden. So programmiert man also ein Droplet!

Fünf Beeps sind natürlich nicht besonders sinnvoll, aber es geht jetzt zunächst einmal um die von Applescript definierten Event-Handler und die Speicher-Optionen des Skripteditors. Dieses Droplet-Verhalten des Skriptprogramms funktioniert übrigens nur, wenn das Skript auch im Dateiformat «Programm» gespeichert wird. Würde es im Dateiformat «Skript» gespeichert werden, würden sich keine Dateien auf das Symbol werfen lassen.

Daran kann man nun schon die Zusammenhänge zwischen den Event-Handlern und den Speicher-Optionen erkennen.

Und jetzt kommen wir auch schon zum vorerst letzten Standard-Event-Handler, der eine spezielle Speicherung des Applescripts verlangt, und den wir hier vorweg besprechen.

on idle-Handler

Während die meisten Scripter den on run- und on open-Handler kennen, fristet der on idle-Handler eigentlich eher ein Schatten-Dasein und kann fast schon als kleiner Geheimtipp durchgehen. Denn er bietet durchaus interessante Möglichkeiten. Damit der on idle-Handler überhaupt funktioniert und greift, muss das Script im Dateiformat [Programm] mit der Option [x] Nicht automatisch beenden gesichert werden (siehe letztes Bildschirmfoto). Ein derartiges Applescript mit diesem Handler hat nämlich die Aufgabe, Dinge ständig zu wiederholen, und damit auch dauerhaft zu laufen. Ein Programm also, dass ständig eine oder mehrere Aufgaben erledigt/überwacht.

Bleiben wir zunächst mal bei dem blödsinnigen aber einfachen Beispiel mit den beep's und sehen uns mal so ein Programm an. Ach nein, bessere Idee: wir benutzen mal die Sprachausgabe (Befehl say gefolgt vom zu sprechenden englischen Text in doppelten Anführungszeichen, also z.B. say "some words"). Das ist einfach und macht die Sache noch etwas anschaulicher:

-- Dieses Script als "Programm" mit der Option "nicht automatisch beenden" sichern!

on idle
   say
"on idle handler"
   return 3
   beep
end idle


on run
   say "on run handler"
end run

on open
   say
"on open handler"
end open

 Im Scripteditor öffnen

So. Was haben wir da jetzt. Und vor allem: «Was passiert jetzt?». Und genau das schauen wir uns jetzt mal genau an. Wenn ich das Script im Skripteditor starte, dann wird nur der Teil ausgeführt, der im on run-Handler steht. Das sollte uns jetzt aber nicht weiter verwirren, sondern ist ganz normal. Wir sagen ja schliesslich nur «ausführen» (run). Danach wird das Skript beendet, und wir landen wieder sicher im Scripteditor. Pfff, das war jetzt aber nicht so spannend.

Sicherst Du das Skript jetzt aber als Programm mit der richtigen Option (s.o.), und startest es dann per Doppelklick aus dem Finder, wird wieder zunächst der Teil im on run-Handler ausgeführt, obwohl er an zweiter Stelle steht, denn: wir starten es ja per Doppelklick (run)! Die Reihenfolge der Handler im Script hat in diesem Fall also überhaupt keine Bedeutung. Nachdem der run-Teil komplett abgearbeitet ist, beginnt das Script sich zu langweilen und springt dann in den «Langeweile-Handler» (on idle). Der Befehl wird angesagt: "on idle Handler". Das return 3 bewirkt in diesem Fall (kleiner Hinweis: return hat in AppleScript auch noch andere Bedeutungen), dass genau 3 Sekunden nach dem Abarbeiten des Handlers das Skript wieder zum on idle-Handler zurückkehrt, und somit die darin befindlichen Kommandos erneut ausführt. Das geht nun so lang, bis ihr dem Ganzen ein Ende bereitet indem ihr das Skript mit Quit beendet.

Dem aufmerksamen Leser wird jetzt nicht entgangen sein, dass das beep im «Langeweile-Handler» überhaupt nicht ausgeführt wird. Das liegt daran, dass es hinter dem return liegt, und somit niemals zur Ausführung kommt, da mit diesem return der Handler verlassen und nach 3 Sekunden neu betreten wird. Es macht also überhaupt keinen Sinn, Kommandos nach so einem return innerhalb des handlers zu positionieren.

Mit so einem on idle-Skript lassen sich z.B. gewisse Dinge überwachen, und Aktionen bei Eintritt der Bedingungen in Bewegung setzen. Hier mal ein Beispiel für sowas:

-- Dieses Skript als "Programm" mit der Option "nicht automatisch beenden" sichern!
on idle
   if ((count of windows of application "Finder") > 1) then -- Prüfung einer Bedingung
      close window 2 of application "Finder" -- Ausführung der Aktion, wenn die Bedingung zutrifft
   end if -- Ende der Prüfung
   return 10
end idle

 Im Scripteditor öffnen

Sichere das Skript wieder mit der Option «nicht automatisch beenden» als «Programm». Starte es dann aus dem Finder (es bleibt dann offen), und öffne anschließend enfach einmal einige Fenster im Finder und warte dann einige Zeit... Was passiert? Du wirst sehen, das Skript-Programm wird Dich alle 10 Sekunden von einem Fenster befreien, bis schließlich nur noch eines übrig ist. Öffnest Du wieder ein/zwei Fenster, beginnt das Spiel von vorn. Wenn es genau das ist, was Du schon seit Jahren gesucht hast (was ich nicht denke), dann lass es laufen und nimm es am besten in deine Login-Items auf :-). Wenn nicht: gib ihm einen Groschen, schieß es ab und schmeiß es in die Tünn. Du weißt jetzt ja, wo du es dir wieder beschaffen kannst ;-).

Auf jeden Fall sollte die Funktionsweise und der Sinn eines Stay-Open-Scripts mit On-Idle-Handler anhand dieses kleinen Beispiels klar geworden sein.

Achso, und von wegen: «...vorerst letzter Standard-Handler, den wir besprechen müssen». Einen hab ich leider noch:

on quit-Handler

Den on quit-Handler kann man ganz gut im Zusammenhang mit dem on idle-Handler gebrauchen, denn wenn man ein Script schreibt, daß ständig oder über einen längeren Zeitraum laufen soll (On-Idle-Script, Stay-Open-Script). Dann möchtest du natürlich nicht, dass dieses Skript willkürlich oder aus Versehen beendet wird. Und genau hierzu kann der on quit-Handler verwendet werden.

Wie der Name bereits vermuten läßt, handhabt man innerhalb dieses Handlers das Verhalten des Skripts bei der Beendigung durch den Benutzer. Der Code innerhalb dieses Handlers wird also aktiv, sobald das Skript per ⌘Q oder Menü «Beenden» (oder wie auch immer) gestoppt werden soll. So ein on quit-Handler könnte z.B. so aussehen:

on quit
   activate
   display dialog "Really Quit?" buttons {"No, I will ask my Mom. Continue.", "Yes, I know what I do."} default button "No, I will ask my Mom. Continue."
   if button returned of result = "Yes, I know what I do." then
      -- place things here to perform them before completion of the script
      continue quit
   end if
end quit

 Im Scripteditor öffnen

Also gehen wir die Zeilen mal kurz durch: die zweite Zeile (activate) bewirkt, dass das Script aktiviert wird. Das ist wichtig für die darauf folgenden Zeilen, da diese einen Dialog anzeigen. Damit dieser Dialog im Vordergrund angezeigt wird, und nicht hinter dem zwanzigsten Fenster, holen wir das Script mit activate in den Vordergrund. Dann folgen die Zeilen für den Dialog (ich gehe später noch mal darauf ein, aber vielleicht kennt ihr Dialoge ja schon). Es wird gefragt, ob das Script wirklich beendet werden soll, oder besser nicht. In der vierten Zeile erfolgt dann die Abfrage (Bedingung), welcher Button gedrückt wurde. Wenn der Benutzer den Beenden-Knopf gedrückt hat, wird also die sechte Zeile (continue quit) ausgeführt, also das Skript-Programm tatsächlich beendet. An dieser Stelle könnte man auch noch andere Dinge ausführen lassen, die am Ende des AppleScripts passieren müssen (z.B. Aufräumarbeiten, Speicherung von Daten oder Variablen, ...). Ist die Bedingung nicht erfüllt (sprich: der Beenden-Button wurde nicht gedrückt), dann wird der on quit-Handler wieder verlassen, und das Script läuft somit weiter. Der on quit-Handler ist somit dafür zuständig, Dinge abzuhandeln, die beim Beenden des Applescripts stattfinden sollen.

Und hier geht's demnächst weiter...



Kommentar schreiben

Markus |  22.10.2015, 21:24:12 |  Familie.Beermann@googlemail.com  77.23.206.36 = ip4d17ce24.dynamic.kabel-deutschland.de
Hallöchen, bin über Dein iPhoto-Script auf dieses Tutorial gestoßen und muss sagen, sehr gut aufgebaut. Hoffe dass es mir damit gelingt, das Skript auch an Fotos anzupassen :-) Viele Grüße Markus 

armin maier |  09.12.2011, 12:45:20 |  kontakt@das-atelier-mainz.de  87.162.199.158 = 87.162.199.158
hallo - Hallo H =:o) L G I - (das scheint sich ja als anrede eingebürgert zu haben :) ) ...bin anfänger im scripten und beim suchen nach "automatisierungsmöglichkeiten" auf deine seite gestoßen ! es ist eigentlich alles schon gesagt worden : lob und toll usw. dem ich mich komplett anschließe. ich speziell suche grade nach der möglichkeit ein script zu einer bestimmten zeit zu starten....sicher pippifax denke ich :) aber bin zu doof was zu finden dazu. freue mich / freuen uns was zu hörengruß,armin  

Maik R. |  26.06.2011, 23:26:02 |  78.55.199.175 = x4e37c7af.dyn.telefonica.de
Kann mich meinen Vorrednern nur anschließen. Klasse Tutorial. Vielleicht findest du wirklich noch Zeit dein Werk zu vollenden. Hat mir bisher schon sehr viel Tips gegeben und ich denke das wird es Anderen auch noch tun. Aber hier und da fehlt noch was wo man echt noch mehr gewusst hätte.Gruß Maik 

Seppi |  01.05.2011, 12:23:48 |  josweber@web.de  83.77.168.177 = 177.168.77.83.dynamic.wline.res.cust.swisscom.ch
Also, H =:o) L G I, jetzt gib Dir mal einen Ruck, und mach weiter. Es ist jetzt schon wieder ein Monat verflossen, also wirklich Zeit, weiterzumachen. Bis hierher sieht das Ganze ja sehr ordentlich aus, klar, verständlich und auch sehr leserfreundlich geschrieben...weshalb ich gerne die Fortsetzungen lesen würde.GrüsseSeppi 

H =:o) L G I |  30.03.2011, 23:19:45 |  91.35.6.179 = p5B2306B3.dip0.t-ipconnect.de
Hallo Marcus. Danke für dein Lob, und ich geb Dir in allen Punkten recht... Ja, ich muss mich wirklich mal dazu aufraffen dieses Tutorial weiterzuführen, aber die Zeit... Naja, ein vollständige Einführung werde ich hier niemals fertig bekommen, aber ein paar wichtige Punkte sollte ich schon noch abhandeln. Ich weiß auch schon, welche Dinge es sind, die für Anfänger immer wieder Fragen aufwerfen und genau diese Dinge werde ich hier noch einmal abhandeln. Aber Du hast prinzipiell recht. Ich sollte mich mal dazu aufraffen... Vielleicht hast Du es ja geschafft, mir den nötigen Anstoß zu geben... Ich wünsch Dir viel Spaß beim skripten! 

Marcus |  30.03.2011, 15:47:32 |  hoschis@gmx.de  77.181.105.236 = x4db569ec.dyn.telefonica.de
Hallo H =:o) L G I (wie auch immer das ausgesprochen wird),das Applescript-Tutorial finde ich wirklich gut! Bitte vollende dein Werk für die Nachwelt, denn es ist verständlich und witig.Leider schreiben zu wenige Leser Ihre Meinung hier nieder und so tendiert das Feedback sowie die Motivation für den Autor gegen Null!Mit freundlichen Grüßen, Marcus 

H =:o) L G I |  17.08.2009, 18:21:40 |  89.53.75.208 = 89.53.75.208
Tja, "demnächst" ist natürlich ein dehnbarer Begriff... vielleicht habe ich ihn gewählt, weil ich schon vorher nicht wusste, wann ich die Zeit für die Fortsetzung finden würde... Aber es geht's schon weiter. Wer gern ein Tutotial zu einem bestimmten Thema schreiben möchte, ist herzlich eingeladen... - Ein Stay-Open-Script ist ein Script, das mit der Option "Nicht automatisch beenden" gesichert wurde, eben so, wie beschrieben für den "idle-Handler". Gruß, H =:o) L G I 

reldeisnoi |  16.08.2009, 15:13:08 |  79.200.124.202 = p4FC87CCA.dip0.t-ipconnect.de
wann demnächst geht es weiter?was ist ein Stay-Open-Script? 



Powered By CMSimple Design By NMuD Top