[Bug]: Linux working directory issues with file chooser and `juce_getExecutableFile`

[sauraen]

trafficstars

Detailed steps on how to reproduce the bug

There are two aspects of this issue; each of them could be argued whether it is a JUCE bug or not, but the combination of them results in unexpected results to the developer.

First: on Linux, File::getSpecialLocation(File::currentApplicationFile) calls juce_getExecutableFile in juce_posix_SharedCode.h. The method here gets the path the user typed to run the program, e.g. ../build/my_program, and resolves this relative to the current working directory. The issue here is that if the program changes its working directory, such as by new_directory.setAsCurrentWorkingDirectory(), the results from File::getSpecialLocation(File::currentApplicationFile) will be silently wrong results, such as /home/build/my_program if the new working directory has become /home/username. I'm not sure there is a way to get the executable if the directory has been changed, so maybe this needs to be done at application startup (e.g. in a constructor of a class with an instance allocated statically) and kept in a static variable.

Second: I recently switched to LMDE 5 Elsie, and on this platform, the native file chooser box changes the program's directory to the directory being shown in the box. This is of course not JUCE's fault, and I'm currently working around this with

        File oldwd = File::getCurrentWorkingDirectory();
        bool hitokay = box.browseForFileToOpen();
        oldwd.setAsCurrentWorkingDirectory();

However, since the juce_getExecutableFile behavior is dependent on the working directory not changing, perhaps the FileChooser class should get the working directory before showing the modal window and set the working directory back to the same value after it is closed.

Whichever approach is desired for fixing the issue, the current behavior combining them--File::getSpecialLocation(File::currentApplicationFile) results start being wrong after a FileChooser has been opened--is an issue for the developer.

What is the expected behaviour?

File::getSpecialLocation(File::currentApplicationFile) always gives correct results, regardless of whether a FileChooser window has been opened or not.

Operating systems

Linux

What versions of the operating systems?

Tested on LMDE 5 Elsie.

The dependence of File::getSpecialLocation(File::currentApplicationFile) on the working directory is in POSIX common code, so it likely affects Mac too.

The file chooser behavior may be specific to this specific window manager (Cinnamon).

Architectures

x86_64

Stacktrace

No response

Plug-in formats (if applicable)

Standalone

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• [X] I agree to follow the Code of Conduct