Fix PATH environment handling for macOS application bundles. Fixes #941

[snechaev]

This pull request implements a workaround to address the issue of a restricted PATH environment in macOS app bundles. It will "steal" full PATH from the "normal" user environment and inject it to the current process, allowing CLI tools such as dotnet to be properly located. The does not affect non-macos environments and the situations when the app is runned from a terminal or from the IDE.

Fixes #941

[snechaev]

I tried to run the fix as earlier as possible, but still not sure that it is a correct place.

[akoeplinger]

@snechaev @KirillOsenkov I think I'd prefer running this only when you actually run build through the UI (we can also just modify the PATH of the ProcessStartInfo there, not of the whole binlog viewer process).

I never build through the UI and this will make startup of the app slower for everyone.

[KirillOsenkov]

how much does this cost though?

[akoeplinger]

probably not much, but seeing the process.WaitForExit() code waiting indefinitely and knowing how hard it is to not write Process code that deadlocks I'm a bit cautious :D

[snechaev]

@akoeplinger The rationale behind choosing a global environment modification is primarily around maintainability and preventing future regressions:

• We currently don't have a centralized wrapper for Process.Start. There are already multiple disconnected places that invoke dotnet. Furthermore, we expect more external process calls in the future (e.g., external diff tools, or porting the "Open binlog in VS Code with binlog MCP" feature from the Windows version). The global fix automatically covers all present and future invocations.

• Discoverability of the bug: While setting environment variables locally for each Process.Start is arguably safer, it relies heavily on developers remembering to apply it on each new or modified Process-related code. Because this issue is highly specific - manifesting only at runtime, only on macOS, and only when launched as an app bundle - missing a local fix would be very easy to overlook and hard to catch during standard testing.

• Scoping the fix specifically to the Build/Rebuild actions might be too narrow. As mentioned, features like opening VS Code or running diff tools will also need this corrected environment to function on macOS. We could implement a lazy initialization method to be called before every Process.Start (or, again, just to modify environment variables of the specific Process instance), but that brings us back to the risk of developers forgetting to invoke it.

Are there alternative approaches I might be missing that will allow to avoid the "global" fix and will not introduce a significant risk of the regressions and broken new functionality?

@KirillOsenkov, I took some measurements and found that executing InheritUserPath() takes around 45-50ms on my not so fast 3-year-old mac mini.

[akoeplinger]

ok, I didn't know there are multiple places where we invoke dotnet. let's just wait and see whether this actually causes issues :)

[KirillOsenkov]

I can live with 50ms, thanks for measuring :)

[snechaev]

I skipping any errors here (and also there is a early return if a the process was null). We have no UI at this stage so we can't provide user with any diagnostics. But ignoring errors may be fragile. So, is it a better way to handle this? May be logs, asserts (for debug time), etc?