Environment Variables Behavior On Haiku

I agree that BRoster::Launch() should work properly. If you look at /system/data/launch/system, you see that it doesn’t setup any environment.
It just starts the system servers, and ‘autologin’, which will then start a new session via BLaunchRoster::StartSession().

Then the interesting stuff happens: the user session is created, and /system/data/user_launch/user is evaluated. The “desktop” target will initialize the environment via SetupEnvironment.

Therefore, if you let a system server launch a user application, it misses any environment.

4 Likes

My SystemManager utility can be used to see process hierarchy and what process launched by what process.

Tracker is responsible for handling file open requests and selecting compatible applications depending on MIME type. It can also launch applications if opened item it an application.

I think that it is a good idea to handle BRoster::Launch requests by launch_daemon.

That’s how it is done now, sure. But it doesn’t mean it is the correct way to do things.

For example here in the open command line tool: open.cpp « bin « src - haiku - Haiku's main repository

In the case of opening files I would have expected the requests to go through registrar, rather than Tracker, for example? But it would create the same problem, I guess, because registrar is in the “system” session?

It become de-facto API and it is used by 3rd-party applications including my SystemManager (to open directories). It can’t be easily changes without breaking a lot of things.

2 Likes