Send a small Apple event

An Apple event is a structured message one process sends to another: give me this property, perform this command. AppleScript is the language most people use to send them — every tell application block compiles into Apple events under the hood.

Start with a read-only request. Ask Finder for the path of the front window:

tell application "Finder"
  POSIX path of (target of front window as alias)
end tell

Run it in Script Editor and inspect the result. With a Finder window open on Downloads, the result pane shows:

"/Users/flavio/Downloads/"

The first run does something else too: macOS asks whether Script Editor may control Finder. That is a TCC permission prompt, and it appears once per pair of controlling app and target app. Approve it and the grant appears under System Settings → Privacy & Security → Automation. Deny it and every future event to Finder fails with error -1743, “Not authorized to send Apple events”, until you change it there.

Now break the script on purpose. Close every Finder window and run it again. It errors, because there is no front window to ask about. If Finder has no open window, the script needs an explicit fallback:

tell application "Finder"
  if (count of windows) is 0 then return POSIX path of (desktop as alias)
  POSIX path of (target of front window as alias)
end tell

AppleScript errors are part of the contract, not messages to ignore. The scripts that survive are the ones that decide in advance what happens when the assumption behind a request turns out false.

Keep events small while you learn an app: one property read, one result checked. A tell block that chains five operations tells you nothing useful when it fails in the middle. Once each event is verified on its own, combining them with shell automation later is assembly, not archaeology.