On Feb 24, 2014, at 5:15 PM, David DeHaven <david.deha...@oracle.com> wrote:
> >> Application. Signed, not sandboxed. Something recently, Lion -> Mountain >> Lion maybe? seemed not to work unless I signed it. So I self-signed. I first >> looked at this a while ago I think before it was even signed and still >> couldn't get it to work. > > I don't know what the core issue is but my own (personal) experience has been > that LSEnvironment isn't reliable. > > >> I'm trying to interface 3rd party code to my HalfPipe application. It's a >> JSR 223 interface to the R language. >> https://rforge.net/rscript/ >> It seems to require a R_HOME environment variable set. Which so far, I can't >> give it with LSEnvironment through the plist. > > Requiring R_HOME to be set in the environment seems sketchy to me. At worst > you should be able to set it through a system property, not rely on the > environment. Is it open source? Maybe it could be fixed and contributed back. > > The ugly workaround might be to drill down through JNI to call setenv, if it > can be done early enough. Given LSEnvironment not seeming to work at all. I should probably set up some other test cases and see if this seems to hold consistently. But given that, I am already considering the workarounds. The property is required by the native code, getenv(), where System.property not quite as preferred as in Java? Anyhow, current efforts on the 'ugly workaround'. Somehow do a setenv myself. Thanks. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter
