Need a Macro to Capture the Unix (POSIX) Path of the Currently Active Document in the Front Application

it works perfectly even with multiple tabs, and I added the script to my Pages and Numbers Palettes.
thank you very much.
I often work in Scrivener I don't know if you are familiar. A Scrivener file is called a project and it contains multiple documents.
I can capture the document name no problem, but I can't capture the project UNIX. Would you have any idea of how to do so ? If not @gglick perhaps has an idea.

Have you tried @ccstone’s macro from the link above?

For me (Scrivener 3.1.3 trial) it perfectly returns the POSIX path of the project:


.scriv is the project bundle, right?

thank you for your suggestion.
The macro did not work in Scrivener 3.1 when multiple tabs were open.
Thanks to @JMichaelTX I now have a perfect solution and learned a lot about KBM macro programming in the process.
Macro does not work : insert file name and path

I acknowledge that you are fine with a different solution, but it may be of interest for other readers who are working without PathFinder:

Still referring to @ccstone’s macro, it works for me also with two projects open in tabs, like this:

“Untitled 2” and “Untitled” are projects. When I run the macro it returns the POSIX path of the active tab (project).

then I must admit that I was mistaken. thank you for the correction.

If @ccstone’s macro works for you as it does for me (with projects in tabs), and if my Pages-specific script works for you in Pages (and similar), then my tip is to…

  • use a proper AppleScript like my Pages example if the app is scriptable (Pages, Numbers and lots more)
  • use Accessibility scripting (via "AXDocument", ccstone’s script) if the app does not provide an AppleScript dictionary
  • try my Recent-Files approach in the (hopefully) rare cases where both of the above fail.

Thanks to KM it shouldn’t be a problem to have the right script executed when a specific app is frontmost.

But if you aim for an all-in-one script that works with most apps (without having to use specific scripts), then go the "AXDocument" route (ccstone’s script).

IMO this is still preferable (by a comfortable margin) to taking a detour via PathFinder (or any other third app).

Unless you explicitly want to go via PathFinder. In this case it was me who misunderstood. (But then you should probably add “PathFinder” to the topic title…)

Just my tip.


I will look at all of it again. Pathfinder is not ideal: the PF app flashes on the screen for a few seconds and back to Scrivener. I will follow your advice. thanks very much

1 Like

I'm resurrecting this thread because I have the same question as the title and the above isn't working for me.

The above works well for me with Pages, but when I substituted TextEdit for the application name, I get:

error "Can’t make file of document 1 of application \"TextEdit\" into type text." number -1700 from file of document 1 to text

So, obviously, TextEdit is not a scriptable with AppleScript as Pages is. Now I can, of course, use Chris Stone's macro, cited by JMichaelTX above.

But in my current case, I only need it to work with TextEdit. (I'm working on using Execute Shell Script to tweak the RTF of a TextEdit file with SED to change the default font and margins.)

Does anyone know how to get the POSIX path of the current file from TextEdit as straightforwardly as @Tom gets it from Preview above?

Chris's macro works for me, so my actual task is solved. I'm just curious to know more about scripting TextEdit, if anyone has details to share.

With TextEdit, this returns the POSIX path for me:

tell application "TextEdit"
	path of document 1
end tell

Hey August,

Well that's definitely true, but you need to actually read the dictionary of an app to figure out what syntax it needs for a given task.

After that you need to actually test to see if you can make what the dictionary says work in real life. That sometimes is not as easy as it should be and may take some research on the net to discover how the syntax actually works.

Not all apps use the same syntax for similar objects and operations (unfortunately), and there are inconstancies even amongst Apple's own apps (shamefully).

This is Script Debugger 5's Dictionary Window on OSX 10.14.6. (Script Debugger 8.0.3 is the most up-to-date version, but I have reasons to use SD5 still on this machine.) Note that it makes discerning object hierarchies relatively simple.

I really dislike Apple's Script, but even it can be coaxed into revealing TextEdit's document class:



At $100, Script Debugger is very pricey for this kind of playing around. If I had an employer to reimburse me for all the productivity it would provide, that would be different. Does the Lite mode do all this? I have a hard time telling from the web pages that are encouraging me to buy it.

Download it and see for yourself...

I found the Feature Comparison page that I was frustratedly missing earlier.

It mostly looks like productivity enhancements, which is exactly the kind of paid/free difference that I like to see. Code folding, auto complete, clippings management, etc.

The most important things seem to be, at first glance, not knowing what the features really do, are:

  • Manifest
  • Status bar
  • Implicit parent script
  • Implicit tell target
  • Tell Context inspector

For my current purposes, Dictionary Inspector is in the Lite version, so that's a win.

Works for me, too. Thanks!

Since this is the "special case" of Text Edit, and not the generic "front application" of the Original Question, I don't feel right about marking the question "Solved" -- and I can't anyway because it's already been marked "Solved" with answers that didn't work for me.

But for the specific case that I needed, and why I reopened the old thread, it works.

And thanks to Chris @ccstone for the push to look at Script Debugger for being able to find out more special case details, since Apple's own apps are not consistent.

Quoting myself from 2019-09:

Though I would every day still prefer the specific solution, bc the “universal” solution will be subpar in most cases..

Even if I had to write a function for universal usage, I'd address specific APIs with priority, and only then throw in the "universal thing" as fallback, like eg this pseudocode:

local function do_the_right_thing()
   local path
   if app == 'A' then
     path = specific_path_retrieving_function_of_app_A()
   elseif app == 'B' then
     path = specific_path_retrieving_function_of_app_B()
      path = "AX…Document………" -- "Universal" AppleScript assault at generic GUI elemements.
   return path or "Sorry mate, nothing to return."

Do not copy the above lines, it is just pseudocode, trying to showcase the idea.



Sort of depends of the definition of Playing Around :wink:

Used it for 4 or 5 years in continuation, it is really good, but now not upgrading, because I do just maybe 3 or 4 tricky scripts per month. Non-tricky script -> No need for SD. (Though still useful, especially if you are new to AppleScript.)

PS: I probably will upgrade, just to support the guys who write and maintain this, though I currently do not really need it. It is good to have a good AS editor around; the one provided by Apple sucks (still OKish for basics, but that's it.).

1 Like

I just leech on on people who have it, and ask in the KM forums :slight_smile:

1 Like

Buddy, can you spare a dictionary lookup for me? :wink:

1 Like