libsdl-org
Handling of current directory for Haiku
Hello,
I think this piece of code is causing me a problem: https://github.com/libsdl-org/SDL/blob/b6ae281e97c4e4680a9010e7e13fe1222c0bcd4b/src/core/haiku/SDL_BeApp.cc#L121
The origin for this is a difference in behavior between Linux and Haiku:
- In Linux, when an application is started from the GUI, its initial working directory will be the directory where the executable is located
- In Haiku, it is the user home directory
This difference, however, does not apply when an application is ran from the command line.
We have introduced this patch in SDL originally, to allow games to run when started from the GUI in Haiku (they would otherwise not find their resources). This was in SDL1.2 days, I am not sure if that still applies with SDL2, but I guess so, since the patch is here.
Anyway, the result is that some things won't work as expected. For example, we're currently using gitk with a version of tcl/tk that renders graphics using SDL2. In this situation, gitk ends up being started in /boot/system/bin/, where the wish interpreter is installed, instead of in the git repository. And it is not happy.
I'm not sure what can be done about this. Should there be a standard way in SDL to locate the executable and its associated resources? Should we remove this code from the Haiku support and start patching all games instead? (that's what we did for SDL1.2 games) Should we fix this patch to check if the app is being run from the command line or not? (I think our Allegro port attempts something like that, by detecting some environment variables that are set only if ran from Terminal)
Should there be a standard way in SDL to locate the executable and its associated resources?
There is, in SDL2:
https://github.com/libsdl-org/SDL/blob/7ec9a4385a0829ef2f7b101ec93f68065ddd2571/include/SDL_filesystem.h#L40
Should we remove this code from the Haiku support and start patching all games instead?
macOS is in a similar position: launching things from the command line works like Unix, you inherit the current working directory, but if you double-click an app in the Finder (the desktop UI), the current working directory will be "/".
The best plan is probably to find a way to decide between these two cases and set an explicit working directory only if you were launched from the GUI (perhaps we can examine the parent process for a specific process name, or it has a reliable process ID or something?).
The simplest way to detect being launched from the GUI is to check the existence of the TERM environment variable (this works in Haiku at least, I don't know about MacOS).
You can find my patch here: https://github.com/haikuports/haikuports/blob/d08aae56febefbb268a5941ac5ce22da5ed533de/media-libs/libsdl2/patches/libsdl2-2.26.4.patchset#L455
(in the same file there are some other patches, I don't know if they are already upstreamed or not)
It is also a problem with 7kaa on Haiku: the application already changed the current directory, but SDL_Init() then changes it again to the executable directory. I had to patch to restore to the expected directory.
https://github.com/haikuports/haikuports/commit/7892b9e785cc51caedb3f74bb59766bb95a9697d#diff-b2f5db5c9add1a73b96fd6a9281cadc2f4ac3faeb743a5a4dca3d41ce0335623R57
I'm going to change this (on Haiku and macOS) to never change the current directory, since we have APIs to let the app discover folders it wants to go now, and portable apps shouldn't rely on the current working directory (unless they're command line apps...in which case we should get out of their way!)
This is for SDL3; this will need a fix to sdl2-compat to keep the SDL2 behavior (and maybe SDL2 should have a hint to not mess with cwd, too, I'll think on it).
Ok, as of 663411ff77c18b7c09b5661af96ffac4805d14e1, SDL2 will only change the current working directory if the TERM environment variable isn't set.
PR #10228, when merged, means SDL3 will never chdir at all, and apps should use SDL_GetBaseDir() to find this path if they want it.