Need halp (help) testing native binaries on Mac and Linux

General Discussions
#21

It’s the same on Linux - it’s Windows that behaves oddly! :wink:

You have potentially two things to deal with - finding the directory of your launcher and traversing symlinks to the actual executable script.

Like I said, the NetBeans launcher script works on both. I just looked for an old shell script launcher I had to handle this and it has an identical start to the NetBeans launcher script (pretty sure I got it from a website somewhere), but anyway …


#!/bin/bash
PRG=$0

while [ -h "$PRG" ]; do
    ls=`ls -ld "$PRG"`
    link=`expr "$ls" : '^.*-> \(.*\)$' 2>/dev/null`
    if expr "$link" : '^/' 2> /dev/null >/dev/null; then
	PRG="$link"
    else
	PRG="`dirname "$PRG"`/$link"
    fi
done

progdir=`dirname "$PRG"`

At the end of that, progdir contains the directory holding your actual launcher script. My old script called cd “$progdir”, but you would probably be better working with absolute paths from then.

eg. something like IIRC


"${progdir}/jre/bin/java" ARGS
#22

I… have no idea what that script is supposed to do… or how it does it…

#23

Not really as far as I could tell. I’m sure if you are hardcore at shell scripting some differences do appear, but aside from some commands/tools not being available on one system versus the other for more or less obvious reason, didn’t seem much different.

I do recall this. The devil can in those details…

#24

[quote=Riven]IIRC the working-directory on Mac OS X is the user-dir, not the directory of the double-clicked file / app.
[/quote]
I just spent some time looking into these scripts and by changing the HelloWorld script to run “pwd” and output it to a text file I found out the following:

Line 1 is me double-clicking the .app package from my /Applications folder
Line 2 is me double-clicking the .app package from my ~/Desktop folder
Line 3 is me running ./HelloWorld from a Terminal window after CD’ing into the Contents/MacOS folder (when it was on my Desktop still)
Line 4 is a bit strange as it hasn’t got the capital S on the end of MacOS like the previous line. This was done after moving the .app package back into my /Applications folder
Line 5 was obtained my CD’ing into the /Applications/helloworld.app folder from the Terminal and running ./Contents/MacOS/HelloWorld

/
/
/Users/robwatson/Desktop/HelloWorld.app/Contents/MacOS
/Applications/HelloWorld.app/Contents/MacOs
/Applications/helloworld.app

So all the operations from the Terminal worked pretty much as expected but by double-clicking it we are totally lost as to where the app is running from :confused:

#25

Can’t remember much of the how … did work it out when I first saw it. :wink:

Obviously didn’t explain the “what” very well, though :emo:

This isn’t a whole script, it’s a fragment that goes at the top of your launcher script so that it can find out where it is. Your problem on OSX and Linux is that the working directory is not set to the location of the launcher you click. Once this fragment has run, the progdir variable will contain what you want to be the working directory.

So, if after the fragment you call [icode]cd “$progdir”[/icode], your working directory would then be like Windows - the location of the script. However, it is better (more robust) to call things with absolute locations as the example at the end of my previous post.

The loose how - $0 contains the full path called (eg. your launcher). The naive approach would just use dirname on this to get the directory. The while loop handles the fact that if you or your user has created a link to the launcher script, $0 will be the location of the link instead - the while loop handles dereferencing through links to find the actual launcher location.

#26

Further investigation found me this snippet:

DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )

Not sure exactly how it works but the outcome seems to be is sets a variable (DIR) to the current directory of the script that is being run.

I changed the HelloWorld script to this:

#!/bin/sh

DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
cd $DIR
./jre/bin/java -jar game/helloworld.jar

And it works just fine when double-clicking the .app package in my /Applications folder. Also moved it around a bit and had it in ~/Desktop and ~/Applications and it worked fine in both of those.

Oh, I see someone more knowledgable than me (nsigma) also posted more info on the expanded version of the script. I reckon you need to just put that bit of code in the top of your script and go from there :slight_smile:

#27

theagentd, why don’t you look at my stuff? I use some Java code to convert images into ico format and it’s under a permissive license in the project Apache Commons Imaging:
https://github.com/gouessej/commons-imaging/commits/trunk
I use Ant to call my code. Don’t reinvent the wheel, you’re gonna solve once again the same problems than some developers including me had in the past, i.e with BASH_SOURCE:

I used PackR before writing my own tool (JNDT). I confirm that it works very well with Mac OS X >= 10.8. Our tools work very well under GNU Linux, Mac and Windows. Mine is a bit less documented. You can use Wix toolset to create a MSI file, feel free to use my template (work in progress):

Note that PackR is able to minimize the JRE, you can still do it by yourself. Using Oracle Java instead of OpenJDK is less permissive, look at the Oracle Binary Code License Agreement.

Have you ever used javapackager?

Good luck.

Edit.: Some working native self contained application bundles I made.

#28

Thanks, everyone! I’ll see if I can do some more testing tomorrow!

#29

Interesting. May have to look at that.

I’m using libicns. Judging from that page, this is in use on iConvert Icons - which seems to include a free online converter.

Agree with the sentiment, obviously, but you may want to check the comments below it - a) caveats on cd usage, and b) some bits don’t work on OSX! :wink:

Bear in mind the script code I posted above is called every single time someone launches NetBeans on Linux or OSX. Which reminds me, it has a GPL w/CPE or CDDL header in NetBeans, though nothing in the platform build harness - either way it should be fine to use, just you might want to credit it! :persecutioncomplex:

@rwatson462 - does swapping out the HelloWorld script for this also work? Nothing like coding blind, but I think this should achieve the same with symlink resolution and not using cd. :-\


#!/bin/sh
PRG=$0

while [ -h "$PRG" ]; do
    ls=`ls -ld "$PRG"`
    link=`expr "$ls" : '^.*-> \(.*\)$' 2>/dev/null`
    if expr "$link" : '^/' 2> /dev/null >/dev/null; then
   PRG="$link"
    else
   PRG="`dirname "$PRG"`/$link"
    fi
done

progdir=`dirname "$PRG"`

"${progdir}/jre/bin/java" -jar "${progdir}/game/helloworld.jar"
#30

@nsigma… Yep, that worked fine from multiple directories and also launched from a symlink on the desktop :slight_smile:

#31

Sorry for my lack of accuracy. I convert both images into .ico and .icns in Java and Ant with my contribution to Apache Commons Imaging. Moreover, I tested the script under Mac OS X 10.6.8 a few months ago and a JogAmp contributor tested it under OS X 10.10 (Yosemite). Finally, JNDT supports a fallback on a precompiled binary launcher (from PackR) which is helpful if you’re not satisfied by the script. You can modify them if you want to rename the Java command. I don’t need to use Launch4j to make it work. I’m very happy because I can target an operating system without installing it on my machines, it’s not the case when using some platform-dependent tools.

#32

Sorry, guys. I’m in a bit of a programming slump right now… ._. Hopefully I’ll find the time+motivation to pick this up again soon…

#33

Hi

Why not helping us to fix the remaining bugs in PackR? This one is annoying me:

@nsigma I should look at the Netbeans launch script, thanks.

JNDT can create DEB packages too, it relies on JDeb.