I recently had to add a Mac to my zoo of hardware I’m trying to do productive work on - which prompted me to clean up and document my environment variable importer, which had grown to platform specific functions with lots of code duplication.
On both Windows and MacOS I have properly configured shells with all relevant variables - so it makes sense to query them, instead of duplicating the logic how they create that configuration into Emacs.
On Linux that’d have worked too, but I also have the relevant variables in the systemd user session, and querying that is a tiny bit faster than launching a shell.
I wasn’t aware of that one - seems for my own use my code predates that.¹
Quick check of their code:
They focus on getting it from a shell, and parse results directly. They also make synchronous function calls, and have some code to monitor if the process takes too long. I also went down that path originally, but abandoned it for just ding asynchronous calls on platforms which are too slow.
I also just allow specifying arbitrary commands to get the key/value pairs - exec-path-from-shell runs starts a new sh in non-standard shells and relies on variables being exported to be visible there. It doesn’t look like querying something like systemctl for variables would work, and I’m pretty sure it won’t work on Windows with Powershell or something similar.
Additionally it seems to allow importing all or only variables on a list, while mine also additionally allows all but the variables on a list.
With my implementation setting exec path after execution is optional - but unlike with theirs it’s implemented in a hook, which also allows hooking in arbitrary functions to run afterwards.
¹ I originally wrote this thing probably close to two decades ago to have the same Emacs config running on Solaris and Linux. The reason for starting it was that after an update some tools to talk to my Palm no longer used the correct port from within Emacs - I had the relevant variable set separately in the shell and in Emacs. Pulling this from the shell fixed the problem for the future as well.
I’ve added the async functions when building a configuration for Windows as everything is horribly slow there.
@aard sounds great! I’ll check it out