I’ve corrected your post. Just wrap your xml in
```xml
<your xml goes here/>
```Thanks for getting that plist file displayed. I’ll make a note of the XML insertion technique.
We can consider this one solved.
do shell script "printenv OSA_LIBRARY_PATH"
–The command exited with a non-zero status.
That command doesn’t seem to work here.
(What I’m trying to do is get a list of all the places appleScript will look for libraries, I’m not trying to make appleScript look in specific places.)
Ed,
Below is what Chris Page posted on AS-users in January…
Starting in 10.11.3 the new script-library search-domain order is:
- The bundle of the script that references the library.
- The bundle of the application process that is running the script that references the library.
- The OSA_LIBRARY_PATH environment variable.
- The user domain: ~/Library
- The local domain: /Library
- The network domain: /Network/Library
- The system domain: /System/Library
- Application bundles: ./Contents/Library
Please use the environment.plist as described in my posts. No commands are going to persist through a restart.
You are getting a non-0 exit status because the OSA_LIBRARY_PATH environment variable is not defined. If you want to see which variables are defined, you can issue the printenv command without any parameters:
Same as in [Script Libraries] (https://developer.apple.com/library/mac/documentation/AppleScript/Conceptual/AppleScriptLangGuide/conceptual/ASLR_script_objects.html#//apple_ref/doc/uid/TP40000983-CH207-SW6) in the AppleScript Language Guide
Actually, I think I’m getting the non-zero result because I’m on Yosemite, not El Capitan. (I think that’s explaining several issues here).
Thanks everyone!
The printenv command has been part of Unix since before the earth cooled. I don’t think OS version is the issue in this instance.
But OSA_LIBRARY_PATH is relatively new, right? Just introduced in El Capitan?
Yes. Setting/printing OSA_LIBRARY_PATH will work the same on both OS versions. The difference will be AppleScript only honouring the variable on 10.11.
But I have to say that one should only need to use OSA_LIBRARY_PATH in exceptional circumstances. Library embedding should handle the vast majority of situations.
But I have to say that one should only need to use OSA_LIBRARY_PATH in exceptional circumstances. Library embedding should handle the vast majority of situations.
Got it.
My goal here is to run a script that will display a list of all the libraries AppleScript would see at runtime. The Script would run in SD, and the user (script writer) would be able to select which scripts to use in the current script, and use statements for those would be added in the script, and, if the script is an applet, it would store them in the proper location.
If the printenv returns a non-zero value, then I don’t have to worry about looking any further, right? if it returns a path or paths then I’ll look there.
The one aspect that I have left to deal with is how libraries distributed in script applications bundles are accessed. Do those applets with libraries have to be stored in the same folders as regular libraries for AppleScript to see them?
Ignore OSA_LIBRARY_PATH. It was added essentially for people writing script editors, as a way of designating a directory where they can safely write temporary library files. It’s not for general use.
IMO, that’s generally the wrong way to go about it.
I reckon you’re better off leaving the libraries in ~/Library/Script Libraries until you’re ready to deploy a script. You can easily add code to use them with SD’s existing tools: type “use” and Esc or F5, or write a simple clipping or text substitution. That’s going to save you a time-consuming search, and other mucking around.
When you wish to deploy outside the development Mac and you want them embedded, use a script based on the one here: http://latenightsw.com/deploying-libraries/ . That will add the libraries to the bundle, export a run-only version for deployment, and then remove them.
Let me go a step further: because some future script editor might rely on it, and because if it does so the workaround outlined here will no longer work, I’d recommend @wildcatherder see if he can’t achieve what he wants without using OSA_LIBRARY_PATH.
1 Like
Until yesterday, Script Debugger was finding my libraries using the OSA_LIBRARY_PATH; now it’s not.
The reason it is IMPORTANT to be able to designate a non-standard directory is that I use the TortoiseHg revision control system. I may have different versions of the same-named library script being employed if I have to roll back to a previous version. It is simply not possible to do that with one central location for scripts.
printenv shows the proper path but now I see “can’t get script” error consistently,
I program in several computer languages and AppleScript is the only one that has given me trouble finding its libraries. I can’t be the only person with this problem.
You’re the only one I know of who uses OSA_LIBRARY_PATH.
As you probably know, this is all well outside Script Debugger’s control — library loading is all done by AppleScript itself. All I can suggest is that you log bugs.
The technique described in my Jul '16 post works. It does not work if you try to add a second colon-separated path, despite examples to the contrary online. As long as I only put in only one location for OSA_LIBRARY_PATH, it works. That will have to do.
Thanks for the update.