Wouldn't export PATH="$(dirname -- "$0")" work too? Em seg., 31 de mar. de 2025, 16:19, Brett Neumeier via skaware < skaware@list.skarnet.org> escreveu:
> On 3/31/25 2:10 PM, Damir Simunic wrote: > > >> On 31 Mar 2025, at 21:02, Brett Neumeier via skaware < > skaware@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. > >
