I would like to use DEVONthink Pro to keep track of various shell scripts I’ve written. Basically, what I want is an RTF file with my notes for a specific shell script and an alias to the actual script in /usr/local/bin/ (so that I can easily read its code).
The problem is that while all these shell scripts are of course simply text files, they have execute permissions set. As a result, DEVONthink Pro tries to outsmart me and just displays a Unix file icon instead of the script code when I create an alias to the file with File > Index….
How can I tell DEVONthink Pro to display the script code and not just a fancy icon?
I am able to index shell scripts in /usr/local/bin and read the text content. I can index the original, index the alias, and also drag the alias into the database – in each case the text is readable.
File > Index does not create “aliases” (in the OS X file system sense) – it creates a DEVONthink database record that records the path to the object in the file system. When the indexed item is clicked in the database, DEVONthink uses Quick Look to display the content of the object at the path. So, are you able to navigate to usr/local/bin/myscript.sh and view the content with Quick Look? (With my testing over here, I can.)
You write further down that you name your scripts myscript.sh, and the suffix is indeed the crucial point! I don’t use a .sh (or .pl) suffix for my scripts, I just make them executable, and I thought that this is the problem.
Thanks to your reply I realize that it is not. For instance, normal Unix README files sport exactly the same problem, although they are plain text files without executable permission, but again, also without a suffix.
So the question has to be reformulated in a more general way: Can I tell DEVONthink that a specific indexed file should be treated as a plain ASCII text file (no Quick Look required)?
Yep, I know. I just used the terminology from DEVONthink’s help for simplicity’s sake.
This I didn’t know. Interesting.
Strangely, no, not even for a file with an .sh suffix. So for me, not even appending an .sh suffix would work (but I cannot do this anyway, for other reasons …). Have you installed an additional Quick Look importer for .sh files?
No, I have not installed a Quick Look plugin for .sh – over here .sh is associated with Xcode, but I doubt that matters. Have you reset the launchd database recently? It’s possible there’s something gone wrong there.
Yep, of course launchctl and launchd belong together. Still, I have no idea what this could have to do with Quick Look.
However, thanks to your input that this does work for you, I was able to find the solution:
I still have an Xcode 3.x version installed for compatibility reasons with old source code. This Xcode version contains a source code specific Quick Look generator in Xcode.app/Contents/Library/QuickLook/SourceCode.qlgenerator. Mavericks does not contain a dedicated source code Quick Look generator (I assume source code will be handled by the generic Text.qlgenerator), so it erroneously falls back on the old Xcode version if it exists, but this old Xcode version is incompatible with Mavericks.
So
rm -R […]/Xcode.app/Contents/Library/QuickLook/SourceCode.qlgenerator
qlmanage -r
```fixed the issue.
However, this still doesn't help me, because, as I said, my shell scripts do not have a suffix that could be recognized by [b]Quick Look[/b] …
What I would need is a way to tell [b]DEVONthink[/b] that an indexed file should be treated as plain ASCII text, independent from suffixes or [b]Quick Look[/b] …
Not for me. I have hundreds of scripts which build on each other. Changing all their names by adding suffixes and thereby breaking their functionality if they reference other scripts would result in an administration nightmare.
Besides, I’m a Unix guy who uses the command line a lot. Adding suffixes to script names which at the same time are also command names is the opposite of elegant.
% dothis.sh file | dothat.sh
```instead of
% dothis file | dothat
Besides, it wouldn't solve the issue for e.g. README files, and I won't start and add suffixes to some files in each and every Unix distribution, thereby modifying it – another nightmare if you collaborate.
[quote]
Everything else seems to be a workaround.
[/quote]
From my POV, it's exactly the other way around. Depending on file name suffixes to determine whether a file is ASCII text seems a workaround to me.
In the end, there should be a solution to this problem on an operating system level. But as long as there isn't, it should be no great deal to tell [b]DEVONthink[/b] "treat this file as ASCII". But if I understand you correctly, this would be a feature request … :frowning:
Yes, I suppose it would be. “Treat all files without extensions as plain text”, I guess, unless you know a less general way of stating it. IMO, the more general the requirement, the less likely it is going to be implemented because while it might fix one problem it might play hob with someone else’s data.
Hmmm, you do have a point in that arguably no-one would intentionally index non-readable files in DEVONthink.
I also had the Finder in mind, and there it would probably a mess, as there could be all kinds of files of an unknown type that are not plain text files.
Indexed in DEVONthink, not so much. But I think some error handling would still be required for cases when a user erroneously tries to index a binary file of an unknown type.
So maybe the best idea would be to check for non-ASCII characters, and if some are found, to not treat the file as ASCII text. (BTW, the way I use “ASCII” is supposed to include UTF-8, of course …)
So, you may be right and the general approach might make more sense than the file specific one. But I could also live with the latter, as long as there was any way at all to make DEVONthink display the content of my indexed plain text files without suffixes.
Interesting problem… I’m not seeing an easy way through this one without (1) some under-the-hood DT stuff, or (2) a Unix Executable qlgenerator that operates on files with a UTI of public.unix-executable (and I’m not saying it’s even possible). Hmm…
This is looking some fragile solutions to an edge case. (No disrespect – but I don’t know that a lot of readers are going to resonate with “cannot preview files that have no extensions” )
IIRC, the whole point of this exercise was to be able to view the content of the scripts in DEVONthink, and write up some notes and documentation.
So, maybe just have Hazel monitor /usr/bin/local, copy changed files to a separate folder(s), and add the extension? Index that folder in DEVONthink. That way, if you change a script, Hazel will send a new copy (with extension) over to your documentation folder(s) and you can admire your work in DEVONthink.
Well, as I tried to point out, it’s not only executables that are affected. README files would be another classic example.
In general, probably many files that come more from a Unix side of things where suffixes for text files are the exception, not the norm. So this affects sysadmins, developers etc.
I think the following heuristic approach could work quite well and should be easy to implement:
A new file is indexed in DEVONthink
Does this file have a suffix? → if YES, exit & proceed as you do now
Is this file UTF-8? (There are easy code snippets that can check for this) → if YES, exit & display the file content as UTF-8
Is this file UTF-16? (There are easy code snippets that can check for this) → if YES, exit & display the file content as UTF-16
Are all bytes < 128? → if YES, exit & display the file content as plain 7-bit ASCII
Display the file icon (the current behavior)
Obviously, you don’t need any elaborate code or even a Quick Look generator to display plain UTF-8, UTF-16 or ASCII text.
And to be on the safe side, make this whole behavior an option in DEVONthink’s preferences.
Well, I think all readers/users with a background in Unix & system administration will resonate …
(I don’t have any idea how many % of DEVONthink users belong to this group. But it might be more than you think since arguably DEVONthink is quite useful for the academic community, and in this community, a lot of people use Macs because they are also Unix machines …
I any case, I would hope that my suggestion in my previous post isn’t that fragile …)
But they are not pure UNIX machines and this means you have to deal with the high-level stuff like requiring extensions for QuickLook, etc… So while many UNIX ideas apply, Apple requires US to be flexible, not themselves.
I only pointed out to korm why there might be more DEVONthink users than he thought who would benefit from the solution I suggested.
And my suggested solution was not addressed at Apple, but at DEVON technologies, so it’s irrelevant in this context what “Apple requires”.
I agree that probably the majority of DEVONthink users would not benefit much from my solution, but as long as they aren’t negatively affected (and I cannot see they would), what speaks against implementing a comfortable solution for a possibly not-so-small minority, so much that instead you demand from this minority to be “flexible”? (Demanding “flexibility” from computer users almost always means the programmers were too lazy to implement a better solution. )
In short, what speaks against the implementation of the solution I suggested above? It’s easy to implement, and whoever doesn’t like this behavior, could simply uncheck the respective preference.
Honestly, I could think of more than one sysadmin who would not hesitate to buy DEVONthink for the feature of being able to comfortably collect, index, read and comment on scripts and README files alone …
)
)