Enable lite-xl to be started from a symlink to the deployed binary (#249)

Use resolved executablePath instead of resourcePath to allow lanching
the lite-xl binary via a symlink, like typically done by Homebrew:

/usr/local/bin/lite-xl -> /Applications/lite-xl.app/Contents/MacOS/lite-xl

The resourcePath returns /usr/local in this case instead of
/Applications/lite-xl.app/Contents/Resources, which makes later
access to the resource files fail. Resolving the symlink to the
executable and then the relative path to the expected directory
Resources is a workaround for starting the application from both
the launcher directly and the command line via the symlink.
This commit is contained in:
Ferdinand Prantl
2021-06-03 21:48:15 +02:00
committed by GitHub
parent f23419994d
commit 1eabf99054
2 changed files with 26 additions and 3 deletions
+19 -2
View File
@@ -4,8 +4,25 @@
void set_macos_bundle_resources(lua_State *L)
{ @autoreleasepool
{
NSString* resource_path = [[NSBundle mainBundle] resourcePath];
lua_pushstring(L, [resource_path UTF8String]);
/* Use resolved executablePath instead of resourcePath to allow lanching
the lite-xl binary via a symlink, like typically done by Homebrew:
/usr/local/bin/lite-xl -> /Applications/lite-xl.app/Contents/MacOS/lite-xl
The resourcePath returns /usr/local in this case instead of
/Applications/lite-xl.app/Contents/Resources, which makes later
access to the resource files fail. Resolving the symlink to the
executable and then the relative path to the expected directory
Resources is a workaround for starting the application from both
the launcher directly and the command line via the symlink.
*/
NSString* executable_path = [[NSBundle mainBundle] executablePath];
char resolved_path[PATH_MAX + 16 + 1];
realpath([executable_path UTF8String], resolved_path);
strcat(resolved_path, "/../../Resources");
char resource_path[PATH_MAX + 1];
realpath(resolved_path, resource_path);
lua_pushstring(L, resource_path);
lua_setglobal(L, "MACOS_RESOURCES");
}}