So turn the feature off via the checkbox in the preferences and accept the usability hit of not being able to double-click to open files in external applications.
In case you missed it, that’s Preferences > General > Interface > Double-click opens documents externally. I have it turned off myself. (That might even be the default?)
That’s the OS doing that, as per the article I posted. Nothing to do with DEVONThink, except that you’re using DEVONThink to tell the OS to open the file.
And there’s a similar OS-level connection between executable files with no extension, and the shell, as per the bug report I posted. Any application which allows you a way to browse and open files by handing them off to the OS to deal with is going to have the same problem. Like BBEdit, for example.
The API in question is most likely Launch Services, and the documentation says that the result will be identical behavior to Finder:
Launch Services eliminates apps having to query the Finder to open an app, document, or URL for them. The macOS Finder itself uses Launch Services to perform such tasks. Because the Finder performs no additional processing beyond calling Launch Services, any client using Launch Services for these purposes behaves identically to the Finder.
However, I found that Panic’s Transmit seems to use a different mechanism, and will refuse to open extensionless files unless told which application to open them with. Maybe the DEVONThink team could ask Panic what they’re doing to get that behavior?
At any rate, that wouldn’t solve the general problem, which is that opening common files can cause malicious code to execute. Solving that problem completely isn’t something DEVONThink can do. You aren’t even safe inside DEVONThink — it’ll execute PostScript files without having to launch them externally, for example. I tested with a Mandelbrot program and DEVONThink happily locked up for a minute running it when I selected it in the document list.
Disabling “open documents externally” solves the problem, but removes valuable functionality.
Why should you not be able to open Excel for a document that ends with *.xls or *.xlsx?
What DT is doing or not and what it is handling over to the OS or not, is totally within control of DT respectively the developers from DEVON Technologies!
I don’t understand the rest you wrote, but be assured that BBEdit does NOT execute any files, just because it has executable right.
BBEdit does not even OFFER “opening” a file as long as it does not have a file ending of *.txt or *.md and maybe some more.
So, this is just an example for my view of this - BBEdit does it better than DT.
I literally tested before posting, and it does. If you tell it to open an extensionless executable shell script externally, it runs the shell script.
Right click file, chose “Open With Finder”. That’s what DEVONThink is doing when you double-click, it’s calling Launch Services to open the file, which does the same as opening it with the Finder, as per Apple’s documentation.
(The equivalent of opening the file within BBEdit is opening it inside DEVONThink. In that case, DEVONThink doesn’t execute the file. And yes I tested this too.)
Open the file browser in BBEdit (View > Window Appearance > Show Sidebar), select the test file, right-click / ctrl-click and choose “Open with Finder”. That’s the equivalent of the double-click to launch in external program option of DEVONThink.
You are presenting a way to get BBEdit to open something with the Finder, which is a totally strange idea and exactly which should not be done!
Doing it this way is just plain wrong and DT should not do it this way - this is what I am trying to tell you, repeatedly.
Just because you found a way to get BBEdit to do the same, does not change the regular and normal way, BBEdit opens files - and this is shown in my screenshot above.
You can also get “vi” to execute a shell, but this is not the way it opens files for editing them - please stop with such comparisions. They don’t prove nothing.
My assumption is that the arguments have been truly and thoroughly exchanged here. There are at least two different standpoints, both of which are valid in my opinion. I can easily see how there might be an expectation the “open externally” would not open a text file as an executable, and I can easily see that the argument that DT is not the responsible party here holds water. I honestly don’t think there is additional value in repeating the points which have been made. The original intention was to point out to DEVONtech a potential risk and to ask whether DT has an option to mitigate that risk. The intensity of the risk has been argued differently by both sides, whilst DEVONtech are enjoying a holiday. I suggest we leave it at that - it is for DT to decide whether and how to react both to this thread and to the perceived risk; in the fullness of time, that is.
Thanks for sharing the points of view in this thread, no matter how divergent they may be.
However, I think the thread has come to its useful conclusion for now.
Cheers!
