Hi Jules and ROLI team, there's an issue with the "juce_getExecutableFile()" posix implementation when running a juce-based tool.
Everything works fine if you run "./JuceDemo" or "./full/path/to/JuceDemo" but it fails when JuceDemo is in $PATH and we run "JuceDemo".
You can try this yourselves on Linux or OSX, the steps are:
1 - build JuceDemo
2 - run this:
export PATH=/path/to/JuceDemoDir:$PATH
JuceDemo
3 - Try the "Child Process Comms" and see it fail with an assertion on "ChildProcess::ActiveProcess".
The assertion happens because the Juce code is trying to find the current "JuceDemo" path based on the working directly (usually /home/user), which will obviously fail.
If the path is not relative or absolute (doesn't start with "/" or ".") we need to look up for the binary in $PATH.
Here's a patch to fix this: https://gist.githubusercontent.com/falkTX/0af036871c13389d64e3/raw
PS: This will fix a known Linux issue in a specific juce-based host ;)
Thank you for your patch. However, I think the correct approach is to fall through to getting the executable path via the File::hostApplicationPath special file location constant, when the current target is an executable. For example, changing line 117 of ChildProcessDemo.cpp to
if (masterProcess->launchSlaveProcess (File::getSpecialLocation (File::hostApplicationPath), demoCommandLineUID))
fixes the assertion. I'll add a patch so that File::currentExecutableFile uses the current implementation of juce_getExecutableFile() for shared libraries and falls through to File::hostApplicationPath for executables (which internally reads the target of the symbolic link /proc/<pid>/exe which is more reliable on linux). Thank you for bringing this up!
Yes but your suggested patch to traverse the entries in the PATH environment variable may still return an ambigous result in edge cases where PATH has been changed by the executable itself. I think the /proc/self/exe method is more reliable. If we see bug reports of this failing then I'll obviously rethink this.
