reveal currently open file in finder

[sepulchra]

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 October 28, 2023 by sepulchra

[Stephen_C]

I guess you could link a hotkey to an Automation Task Identify Front App and then link that to Reveal File in Finder. I have not tried so am not sure if you need to get the specific path of the app or whether the Automation Task does that.

 

Stephen

[sepulchra]

Thanks @Stephen_C i tried that but that front app task doesn't output a path so unfortunately that isn't the solve. That is where mind went as well!

[Stephen_C]

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 October 26, 2023 by Stephen_C

[Stephen_C]

I couldn't "put it down” so had to do a little more experimentation. Try running this in Script Editor:

 

set theAppPath to (path to frontmost application)
set thePath to POSIX path of theAppPath

 

Stephen

[sepulchra]

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?

 

 

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 October 26, 2023 by sepulchra

[Stephen_C]

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

[sepulchra]

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

 

[sepulchra]

@Stephen_C I have no idea if that script above is the best way to accomplish this, but the script above works, except if the app has any other floating windows.  

[vitor]

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.

[sepulchra]

Thanks @vitor. One might also ask is command+clicking on the top of a document really such a drag on my time????

[vitor]

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.
  

[Stephen_C]

I much agree with those comments. I just wish I had a little more of your expertise! 😀

 

Stephen

[sepulchra]

@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

 

[vitor]

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.

[sepulchra]

Thank you very much. This me something to learn.

[macrospect]

This is a great discussion on writing workflows, but just in case anyone needs a faster fix, the Go to Current File workflow here still seems to work as of now, and appears to offer the functionality requested:

 

https://github.com/andrewning/alfred-workflows-scientific?tab=readme-ov-file#go-to-current-file