Why won't OSA_LIBRARY_PATH not work as documented for JXA? - objective-c

According to Apple's Developer Docs the Library global allows one to import compiled scripts so they can be used as a library in one's current script. This works just fine if you were to do something like the below code with myLibName.scpt located at ~/Library/Script Libraries:
myLib = Library('myLibName');
myLib.myLibMethod() // Works just fine
But, the docs also claim that one can export an environment variable — OSA_LIBRARY_PATH containing a string of : delimited paths — and Library() would then defer to that list of paths before proceeding to it's default path: ~/Library/Script Libraries. Ya know, like the bash environment variable Path. Here's the relevant piece of documentation below; it describes the path hierarchy:
The basic requirement for a script to be a script
library is its location: it must be a script document in a “Script
Libraries” folder in one of the following folders. When searching for
a library, the locations are searched in the order listed, and the
first matching script is used:
If the script that references the library is a bundle, the script’s
bundle Resources directory. This means that scripts may be packaged
and distributed with the libraries they use.
If the application running the script is a bundle, the application’s bundle Resources
directory. This means that script applications (“applets” and
“droplets”) may be packaged and distributed with the libraries they
use. It also enables applications that run scripts to provide
libraries for use by those scripts.
Any folders specified in the environment variable OSA_LIBRARY_PATH. This allows using a library
without installing it in one of the usual locations. The value of this
variable is a colon-separated list of paths, such as /opt/local/Script
Libraries:/usr/local/Script Libraries. Unlike the other library
locations, paths specified in OSA_LIBRARY_PATH are used exactly as-is,
without appending “Script Libraries”. Supported in OS X v10.11 and
later.
The Library folder in the user’s home directory, ~/Library.
This is the location to install libraries for use by a single user,
and is the recommended location during library development.
The
computer Library folder, /Library. Libraries located here are
available to all users of the computer.
The network Library folder,
/Network/Library. Libraries located here are available to multiple
computers on a network.
The system Library folder, /System/Library.
These are libraries provided by OS X.
Any installed application
bundle, in the application’s bundle Library directory. This allows
distributing libraries that are associated with an application, or
creating applications that exist solely to distribute libraries.
Supported in OS X v10.11 and later.
The problem is that it doesn't work. I've tried exporting the OSA_LIBRARY_PATH variable — globally via my .zshrc file — and then running a sample script just like the one above via both the Script Editor and the osascript executable. Nothing works; I get a "file not found" error. I found this thread-where-the-participants-give-up-hope online; it doesn't explain much. Any thoughts?
On a somewhat related note, the Scripting Additions suite provides two other methods — loadScript and storeScript — that seem like they might be useful here. Unfortunately, when you try to use them, osascript gives you the finger. Though, I did manage to return what looked like a hexadecimal buffer from a compiled script using loadScript. Anyway, any insight you guys can shed on this would be much appreciated. Thanks.

The OSA_LIBRARY_PATH environment variable is ignored by restricted executables when running with System Integrity Protection enabled.
To workaround this limitation you can either turn off SIP, or you can use an unrestricted executable.
For instance, to make osascript unrestricted, you should first make a copy, and then re-sign it with an ad-hoc signature:
cp /usr/bin/osascript ./osascript
codesign -f -s - ./osascript
Once you have the unrestricted osascript, you can run it with the OSA_LIBRARY_PATH environment variable set like this:
OSA_LIBRARY_PATH="/path/to/libs" ./osascript path/to/script.scpt

As a lousy alternative, you can put a symlink at one of the "Script Libraries" folders that osascript would look at and point it to the folder you want. Note that the symlink must be a replacement for the entire folder, it can't just exist inside of it.
rm -rf ~/Library/Script\ Libraries
ln -s "/Your/Custom/Path/Goes/Here/" ~/Library/Script\ Libraries
Tested on 10.13.2

Related

Why are the files called .babelRC and .npmRC? [duplicate]

In my home folder in Linux I have several config files that have "rc" as a file name extension:
$ ls -a ~/|pcregrep 'rc$'
.bashrc
.octaverc
.perltidyrc
.screenrc
.vimrc
What does the "rc" in these names mean?
It looks like one of the following:
run commands
resource control
run control
runtime configuration
Also I've found a citation:
The ‘rc’ suffix goes back to Unix's grandparent, CTSS. It had a command-script feature called "runcom". Early Unixes used ‘rc’ for the name of the operating system's boot script, as a tribute to CTSS runcom.
Runtime Configuration normally if it's in the config directory. I think of them as resource files. If you see rc in file name this could be version i.e. Release Candidate.
Edit: No, I take it back officially... "run commands"
[Unix: from runcom files on the CTSS system 1962-63, via the startup script /etc/rc]
Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up.
Thus, it would seem that the "rc" part stands for "runcom", which I believe can be expanded to "run commands". In fact, this is exactly what the file contains, commands that bash should run.
Quoted from What does “rc” in .bashrc stand for?
I learnt something new! :)
In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command. It is believed to have originated somewhere in 1965 from a runcom facility from the MIT Compatible Time-Sharing System (CTSS).
Reference: https://en.wikipedia.org/wiki/Run_commands
In Unix world, RC stands for "Run Control".
http://www.catb.org/~esr/writings/taoup/html/ch10s03.html
To understand rc files, it helps to know that Ubuntu boots into several different runlevels. They are 0-6, 0 being "halt", 1 being "single-user", 2 being "multi-user"(the default runlevel), etc. This system has now been outdated by the Upstart and initd programs in most Linux Distros. It is still maintained for backwards compatibility.
Within the /etc directory are several folders labeled "rc0.d, rc1.d" etc, through rc6.d. These are the directories the kernel refers to to know which init scripts it should run for that runlevel. They are symbolic links to the system service scripts residing in the /etc/init.d directory.
In the context you are using it, it would appear that you are listing any files with rc in the name. The code in these files will set the way the services/tasks startup and run when initialized.

What is the default path in .desktop files and how to change?

I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.

CMake search path configuration

we working on a C++/CMake project, that needs to run in both Windows and Linux. On Windows, we have to work with a number Visual Studio versions, both in 32- and 64 bit. In order to alleviate dependency issues in our team, we have manually compiled a number of dependencies for each configuration(vs2013_x64, vs2013_x86, vs2012_x64, vs2013_x86...) and installed them (using make install or similar commands) to a common folder for each configuration. Now we have a folder called "vs2013_x64" for example, that contains similar folders as /usr would on linux: CMake, include, lib, share, ...
Now my question is: How do I have to set up CMake, so that it treats this vs2013_x64 folder just like it does /usr on Linux?
I found a number of variables that seem related, for example
CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT. However, setting them to my vs2013_x64 folder for example does not work: FindXXX.cmake files in the vs2013_x64/CMake folder are not found, and even when I manually set the CMAKE_MODULE_PATH to that CMake folder, the Find* scripts are unable to find the include they are looking for, because the vs2013_x64/include folder does not appear to be searched.
A solution that did work was to set the CMAKE_PREFIX_PATH. This is nice and almost what I need, but lets say that on Linux, I would not want it to look at /usr at all under any circumstances. This would not be possible using the PREFIX_PATH solution if I understand it correctly.
From what I understood from the documentation,
CMAKE_FIND_ROOT_PATH is more configurable and has a number of additional variables such as CMAKE_FIND_ROOT_PATH_MODE_PROGRAM, CMAKE_FIND_ROOT_PATH_MODE_LIBRARY and CMAKE_FIND_ROOT_PATH_MODE_INCLUDE. This makes me believe that FIND_ROOT_PATH is what I actually SHOULD be doing - yet I am unable to make it work
Does what I am trying to do make sense? Can anyone clarify when and how to use what? Ideally, I would like a solution that allows me to set the search path to my vs2013_x64 folder on Windows, that defaults to /usr on Linux, but can optionally also be set to another directory containing lib/include/cmake folders. In addition, it would be nice if searching ONLY occurred in the configured path and nowhere else (to avoid mistakenly picking a library that was installed system-wide).
Thanks!

How can I bundle a command line utility in os x application on Mac App Store (using sandbox entitlement)

I have a c++ command line application that I have already compiled into an executable and have added it into my Xcode project. I have also added the "Copy Files" section to the Build Phases tab of the project properties and added my executable with the "Executables" destination. When I build my application I see it in the test.app/Contents/MacOS folder when I View package contents on the test.app that is built.
I also have App Sandbox enabled on the Capabilities tab of the project (so that I can distribute my application through the mac app store.
How can I expose this command line executable that is bundled with my application to the user so that they can run it from the command line (terminal)? I have not been able to find anything on search engines or on StackOverflow about how to get this file (or a symlink to this file) into the users PATH. I tried using an NSTask to create a symlink, but that only works if I disable the App Sandbox (which makes sense). Has anyone done this before? How did you get it to work? Or can these executables only be executed by code within your application?
I don't see a good way to do this. First, a clarification: the PATH is a list of directories that contain executables, not a list of executables; there's no way to add a single executable to the PATH. Instead, what you'd need to do is either put your executable into one of the directories in the user's PATH, or add the directory your executable is in into the PATH.
On OS X, the default PATH is /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin. The first 4 directories shouldn't be modified from the system default, so only /usr/local/bin is a possibility. But creating it (it doesn't exist by default) would require admin (actually root) rights, which isn't allowed by App Store policies. So that's out.
That leaves modifying the user's PATH. The "right" way to do that system-wide is by placing a file in /etc/paths.d, which requires admin (/root) rights, so that's out too. Technically modifying the /etc/paths file would work, but that has the same permissions problem plus it's the wrong way to do customization.
The next possibility is to modify (/create) the user's shell initialization script(s). This'll work, but doing it at all right is going to be messy, because there are several shells the user might use, each with several different possible initialization scripts that the user might or might not have created...
Let's take a very simple case: a user who only ever uses bash, and who doesn't already have any initialization scripts. When a "login" instance of bash starts, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile (in that order), and runs the first one it finds. But your app doesn't know which shell he uses, so you'd better create ~/.profile so zsh and ksh will use it as well. So, your app creates ~/.profile, and puts this in it:
PATH="$PATH:/Applications/MyApp.app/Contents/Helpers"
Great, right? Yup, great, until the user runs something else that wants to set their PATH, it creates ~/.bash_profile, and this overrides your setup. After that, your executable will be in the PATH of zsh and ksh, but not bash. Whee.
And then one day the user decides to use tcsh instead, and it (and csh) have a completely different but equally messy pile of possible init files...

Flash Builder 4.6 linked Resources not working with ANEs and Certs

I'm having an issue with linked Resources in Flash Builder. I work in a team environment where we use Linked Resources extensively. We just started developing ANEs and noticed that while linkedResources are used in the libraryPathEntry, in the buildTargets like anePathEntry and airCertificatePath, the absolute path is stored. I tried editing the .actionScriptProperties files directly, modifying the buildtarget absolute paths to linked resource equivalents using the libraryPathEntry as a guide but FlashBuilder complained when loading the project.
Is there a way to get the buildTargets to respect linkedResources and not save the absolute path? I'm trying to avoid the draconian way where all developers must have the exact same directory structure.
Thanks!
Randy
My team had this exact problem and all attempts to fix it with relative paths or workspace macros (i.e. ${PROJECT_LOC}) failed. It seems as if the team in charge of Flash Builder neglected to support relative paths in these particular dialogs, despite them being supported elsewhere.
Here is what we have done to fix this problem. I am assuming you are on a Mac/Linux or the like. If not, the concept here can still be applied.
Most of our projects already have a "set up" bash script that contributors run when they get code. Inside of that script, we simply set up a couple of symbolic links from the user specific absolute path, to a new absolute path with a "common" user. The script first creates the directory if it does not exist, and then creates the symlinks.
sudo mkdir -p /Users/common/<project>/
sudo ln -f -h -s ~/path/to/certificate/dir /Users/common/<project>/certificates
Obviously you can use whatever you like and whatever makes sense for the common path.
Now, in your .actionScriptProperties file you can change the location pointed to by the provisingFile and airCertificatePath to this new common absolute path.
<buildTarget ... provisioningFile="/Users/common/<project>/certificates/provisionfile.mobileprovision" ... >
<airSettings airCertificatePath="/Users/common/<project>/certificates/cert.p12" ... >
We actually take this a step further (and I suspect you will need to also) and create common symlink paths for the ANE files themselves. This ends up changing the anePathEntry to the common path as well.
<anePathEntry path="/Users/common/<project>/anes/some.ane"/>
You will need to make sure that you either hand edit the .actionScriptProperties file directly, or type in the fully qualified symlink path into the dialogs directly. Any attempt at using the Finder dialog launched by Flash Builder to navigate to the files in the common location resulted in the symlinks being auto-resolved to their actual locations.
The script requires sudo, which as I'm sure you know, will require that the users of it know their root password. Maybe some more bash savvy folks can suggest a way around sudo if this is not an option for you.
This will work for android stuff as well I believe. I don't know if that matters to you or not.
Hope this helps!
It looks like this issue was called out in the Flash Builder 4.6 known issues:
http://helpx.adobe.com/flash-builder/kb/flash-builder-4-6-known.html
https://bugs.adobe.com/jira/browse/FB-32955
The bug is apparently fixed but I haven't been able to check the new Flash Builder 4.7 beta yet:
http://blogs.adobe.com/flex/2012/08/flash-builder-4-7-beta-is-here.html