Sys.executablePath() returns /usr/bin/openfl on Linux

[dukope]

OpenFL 1.2, Ubuntu 12.04, when running openfl test or openfl run, Sys.executablePath() returns:

/usr/bin/openfl

.. instead of the correct path to the built exe. Windows and Mac work ok. This might be a new issue with OpenFL 1.2 but enough stuff has changed in my code since 1.1 that I can't say for sure.

[DavisDevelopment]

Out of curiosity, what language are you attempting to compile it to?

[dukope]

native cpp

[DavisDevelopment]

Hmm.. Do you know any actual C++? If so, you could create an external C++ file for retrieving that information. Here's a link to how to get the info in C++:
http://stackoverflow.com/questions/143174/how-do-i-get-the-directory-that-a-program-is-running-from
Good luck.

[DavisDevelopment]

Also, have you tried just running the executable directly? I don't know much about the Ubuntu handles subprocesses, but your problem could be caused by the fact that the executable that initiated the subprocess that executed your program is located in that directory.

[dukope]

Running the exe directly works fine, as does running through openfl test/run on Windows & Mac. As far as I can tell, this is a problem exclusive to openfl test/run on Linux.

If I had to guess, you're probably right about the subprocess call. However openfl starts the exe on Linux for test/run is different from Mac & Windows. That's the bug I'm reporting here :)

[ruby0x1]

Judging by the code, it should setCwd when running the application, to the applications path.

If you try running
openfl test linux -v and check the output, you should see a line like this :

- Changing directory:
Right before
- Running command:

This is when it happens, or should.

[dukope]

The problem isn't with the current working directory, which is fine. The problem is with the function Sys.executablePath(), which returns the path to the openfl executable ("/usr/bin/openfl") when starting an application with openfl test linux or openfl run linux. The correct behavior is to return the path to your running executable, whether starting directly (works), or through openfl's shortcuts (doesn't work).

Checking hxlibc/Std.cpp, this looks like the Linux code for sys_exe_path:

const char *p = getenv("_");
if( p != NULL )
    return alloc_string(p);
{
    char path[PATH_MAX];
    int length = readlink("/proc/self/exe", path, sizeof(path));
    if( length < 0 )
        return alloc_null();
    path[length] = '\0';
    return alloc_string(path);
}

As DavisDevelopment suggests, depending on how the openfl run/test command starts the subprocess to run your application, this could pick up the openfl executable as /proc/self/exe. The code for the other platforms behaves correctly and always returns your true application path.

[ruby0x1]

Oh yea I misread,

(btw, test is just "build and run" , so really only run is the source of the call)

Looking at the code for the way it runs them from test / run - it uses Sys.command function (for all platforms). Though this seems to be a bug in the cpp side rather than the calling function, specific to linux (in hxlibc).

I will only have a gap later on to have a closer look, but figured I would leave more breadcrumbs while poking around there.

[dukope]

Cool, thanks Sven. This is super low priority for me, just wanted to post the issue here to give a heads up.

For anyone else running into this, the workaround is to check the result from Sys.executablePath(). If it contains "openfl", build the path yourself using Sys.getCwd() and your known app name. Because openfl does a setCwd before running, you're guaranteed to be in the same dir as the exe (on Linux/Windows anyways).

[jgranick]

I personally have been frustrated by this problem. Could you help me understand the scenario?

Does it matter if you target Neko or C++? Does the application run properly if you execute it from the shell instead of running it through "lime test" or "lime run"?

Is this a problem specifically with running through the command-line tools, or does it occur elsewhere?

Thank you!

[DavisDevelopment]

From the way he talks, running directly, or through the command line, works just fine. It's when he used lime test or lime run that the problem manifested.

[dukope]

Yeah I don't have any additional info beyond what's up there. It returns the correct result when run by itself, the wrong result when run through lime test/run. I've only tried with the C++ target.

fwiw, this is my workaround code:

    exeDir = Path.addTrailingSlash(Path.directory(Sys.executablePath()));
    #if linux
    // @@ hack workaround for linux "lime test" bug
    if (Sys.executablePath().indexOf("lime") >= 0)
        exeDir = Path.addTrailingSlash(Sys.getCwd());
    #end

[jgranick]

It's not perfect, but I've used this to improve (I think) the default behavior for OpenFL and the working directory:

openfl/openfl-native@0a995cc

It will first check if "lime.ndll" is present in the current working directory. If launched from the lime tools, it will set the CWD and this will be the case. Otherwise, it will set the working directory to the executable path. This still might not work properly if the application is launched from some types of launchers, but (hopefully) a launcher like that will at least set the CWD so it will work.

Let me know if you think is a good way to handle it, thanks!

[dukope]

That logic seems fine for setting the working directory.

_But this issue has nothing to do with the working directory. It's a problem with the value of Sys.executablePath() when starting an app through lime test/run, and only under Linux._