On 3/31/25 2:10 PM, Damir Simunic wrote:
>> On 31 Mar 2025, at 21:02, Brett Neumeier via skaware <skaware_at_list.skarnet.org> wrote:
>>
>> On 3/31/25 1:48 PM, Damir Simunic wrote:
>>> The TLDR; is that getcwd and s6-dirname do not provide a desired answer when something messes with the process cwd and argv[0].
>>>
>>> [...]
>>> The launched process receives this very minimal environment: default path, CWD set to /, and the name of the service; launched executable is wired to stdout and stdin as configured (or /dev/null by default if not specified).
>> Is there a reason you can't just write a script that sets the environment the way you want and then execs into s6-svscan, and have launchd run that script instead of directly running s6-svscan? That seems like it would be pretty straightforward, unless I'm missing something.
> Any script runs under the same limitations of the minimal environment. `getcwd PATH s6-svscan` would have been enough had it known how to get its own path under launchd. Hence this little modification.
I get that the script will run under the minimal environment, so it
can't just exec straight into s6-svscan. What I'm suggesting is, write a
script that does *whatever it needs to do* to set up the correct
environment.
Like, if there are specific places that the app bundle is likely to be
installed, have the script look in those places and see if that's where
the it is installed. If not -- or if you have no clue where the app
bundle might be installed, or don't want to make any guesses -- start
with `find / -name DevServ.app -a -type d`, and for each such directory
it finds, look to see whether that's the correct app bundle. After the
script finds itself, set up PATH and cwd and everything else the way it
should be set up, and then exec into s6-svscan.
It might take a while to start up the bundle, but it would work around
the broken behavior of launchd.
Received on Mon Mar 31 2025 - 21:19:29 CEST