Jump to content

reveal currently open file in finder


Recommended Posts

I have  a bit of workflow i have been puzzling over. I often have a document open where I want to quickly go to its path in the finder. For example, I might have a numbers file open and I will command+click on the top of that document's window and click on the folder it resides in, which reveals it in the finder.

 

I would love to build a way to do this with a script or maybe there is a way to use an automation task for this so I can assign it to a hotkey. It is something I do often and would love to eliminate the need for the mouse.

Edited by sepulchra
Link to comment

Sorry not to have been more helpful! It seems there may be AppleScript related solutions if you care to dabble with AppleScript.

 

Edit: for, at least, getting the name of the frontmost app this AppleScript works:

 

set frontmost_app to name of (info for (path to frontmost application))

 

I appreciate that leaves a lot more to do…in respect of which, apologies, but I'm short of time just at the moment!

 

Stephen

Edited by Stephen_C
Link to comment

Thanks Stephen .... this got me going. I got this script to work:

 

tell application "System Events"
	set activeApp to name of first application process whose frontmost is true
end tell
tell application activeApp
	set myPath to POSIX path of (get file of front document)
end tell

 

Interestingly, when i run it on any app the first time I get this permission request. I haven't had that kind request to run any other applescript. Any idea why that would be the case?

 

image.png.9ff88f8f54c68eab7b9752049171f95d.png

 

Also some applications, don't return the path and instead return this error "execution error: Preview got an error: Can’t get file of document 1. (-1728)"

 

Edited by sepulchra
Link to comment

Usually when you run a script in Alfred (or, at least, specifically AppleScript) which interacts directly with an app you will see a warning like that. I received a similar warning earlier today when writing a script interacting with the Messages app.

 

Stephen

Link to comment

interesting. 

 

these additional lines work on apps that didn't initially return the path:

 

try
    tell application (path to frontmost application as text)
        (path of document 1) as text
    end tell
on error
    try
        tell application "System Events" to tell (process 1 where frontmost is true)
            value of attribute "AXDocument" of window 1
        end tell
        do shell script "x=" & quoted form of result & "
        x=${x/#file:\\/\\/}
        x=${x/#localhost} # 10.8 and earlier
        printf ${x//%/\\\\x}"
    end try
end try

 

Link to comment

I bumped into this conversation late last night, after you figured out a solution, and I’d just like to mention it’s always a pleasure seeing you tackle a problem together. You’re both so respectful and willing to try stuff that something positive is bound to come out of it even if it turns out that the answer is that something isn’t doable.


With that in mind I will not step on any toes but just wanted to mention, regarding the Preview question, that you can’t count on AppleScript working the same for every app even when it seems it’s doing the same task. For example, WebKit browsers (e.g Safari) and Chromium browsers (e.g. Chrome) have similar AppleScript dictionaries for most tasks but WebKit browsers use currentTab while Chromium browsers use activeTab to refer to the same thing. That makes code reuse more annoying. Also, Chromium browsers can create private windows while WebKit browsers can’t. The AX you’re latching on to is an accessibility thing. Is it the best way to go about it? Maybe, maybe not. Consider the solution a hack but don’t see that as a bad thing: sometimes a hack is all you have. Like GUI automation. As long as you’re using it just for yourself you should be fine; just remember the limitations if you decide to share it, perhaps have someone else try it with a different set of apps you might not have expected. And remember that for Electron apps all bets are off. Anyway, I guess that’s a long way of explaining why there isn’t an Automation Task for it. I have the impression you both like learning about these details, so I thought I’d share.


Have a great weekend, you two! And thank you for the pleasant thread.

Link to comment

Sometimes we spend more time automating a task than it would’ve taken us to do it by hand for the rest of our lives. Some people make fun of that, but I could talk for an hour on all the reasons I think it’s still worth it. So I don’t spend an entire Saturday writing a large essay on all the reasons already popping into my head, I’ll list just two:

  • It compounds. Do it enough times, and what you learn from automating each task makes automating the next one faster.
  • It’s fun.

Link to comment

@vitor i wonder if i could prey upon your good graces one more time. The applescript I'm using outputs the path but with an extra line, which i'm removing in a var utility. But would you be able tell me what in the script is outputting a blank line at the end? I can't seem to sort it.

 

try
    tell application (path to frontmost application as text)
        (path of document 1) as text
    end tell
on error
    try
        tell application "System Events" to tell (process 1 where frontmost is true)
            value of attribute "AXDocument" of window 1
        end tell
        do shell script "x=" & quoted form of result & "
        x=${x/#file:\\/\\/}
        x=${x/#localhost} # 10.8 and earlier
        printf ${x//%/\\\\x}"
    end try
end try

 

Link to comment
27 minutes ago, sepulchra said:

But would you be able tell me what in the script is outputting a blank line at the end? I can't seem to sort it.

 

AppleScript (and JXA) always output a newline at the end. Can be a bit annoying, I agree. You can make it not output a newline by using the Objective-C bridge and having it send to STDOUT but it’s not pretty:

 

use framework "Foundation"

on writeSTDOUT(output)
   set nsOutput to current application's NSString's stringWithString:output
   set nsData to nsOutput's dataUsingEncoding:(current application's NSUTF8StringEncoding)
   set fileHandle to current application's NSFileHandle's fileHandleWithStandardOutput()
   fileHandle's writeData:nsData
end writeSTDOUT

 

You then run that like:

 

writeSTDOUT("Your text here")

 

I’d recommend just slapping a Transform Utility in there to trim it.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...