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

I've read your post several times and I'm trying to understand the question. In your situation is your code the sole "user" of the apps or is there also a human user doing things to the apps that might change what your code is supposed to do? And does the solution have to avoid interfering with the human's work?

If your code is the exclusive user of the apps, then I imagine it's just a case of remembering the path that was sent to each app when you opened the file. but if the question is "what file is the human user working on right now" that might be tricky. That might depend on using AppleScript to avoid interfering with the user, and some apps aren't AppleScript friendly so that could be a problem.

I could be totally walking down the wrong path here. I'm trying to understand what you want to "capture". The name of the file a human is editing? What if the human is editing multiple files at the same time? So many questions.

1 Like


Here are two approaches. You may need to use both.

  1. Acquire POSIX Path of File Associated with Front Window of Front Application -- @ccstone
  2. Script to Get Top file in Recent Files List -- @Tom
1 Like

Awesome knowledge JM. A significant number of user problems require AppleScript to solve. This was probably one of them, assuming that there's a human user involved in this situation, and that's probably a valid assumption.

1 Like

thank you very much !

thank you. When I am in a file: pages, numbers etc, I want to remain in the file and simply paste the posix. @JMichaelTX kindly provides the perfect answer below.

@ronald, please note that both my approach and @ccstone’s approch (as linked by @JMichaelTX here) are workarounds for apps that are not scriptable (= don’t provide an AppleScript dictionary).

Pages, Numbers are pretty scriptable, so you can have it much easier, for example:

tell application "Pages"
  POSIX path of (file of document 1 as text)
end tell

Output is like this:

/Users/tom/_Tmp ƒ/Untitled 2.pages

This is the POSIX path of the frontmost Pages document (assuming it is saved to disk).

1 Like

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.