Overriding the shell script?

[obra]

Hi!

Thank you so much for building this AppImage maker.

I'm in the process of porting a project from electron-webpack to forge and AppImages were definitely one of the trickier "missing bits"

One thing I can't figure out how to do is to inject a custom shell script in as the launcher for the electron app. Is that something there's a way to do?

When we used electron-builder, they had a hook in between building the content of the AppImage and the final packaging we could hook into.

Thanks!

[SpacingBat3]

Hi, sorry for the late response, I've been actually considering if I really want to allow for replacing the whole script rather than allow for injection into the existing one – the thing is, I want the script to be kept minimal but generic enough to guarantee similar results when executing any of the AppImages produced by my maker – after all, all of them are Electron apps. This means:

• I want to use POSIX-compatible syntax for shell scripts (hence #!/bin/sh), giving the choice to people who use different shells who can work as POSIX shell, so whenever users use e.g. DASH, ZSH or BASH, they can use it to run my script (either when running in POSIX compatibility mode like in case of ZSH or normally if shell is already POSIX-compilant), therefore avoiding the dependence on one specific shell. I would prefer for developers depending on my maker not to switch to another shell, an assumption that everyone uses BASH on Linux isn't always the best.
• The implementation for finding Electron binary and executing it is generic enough to work for many applications, so in most cases if some application finds a better implementation it would be better to improve it at upstream so other apps can benefit from it.

I saw your fork and since I saw you mostly need this for initializing Electron with custom flags based on OS, like using Wayland Native. I think simply injecting the script would be enough for that task (you could use set -- <args> "$@" to set custom command-line flags).

Also I plan to mimic a bit the way how original Electron Forge makers work (at least oddities people might be used to or way you configure my maker) and I'm kinda curious how e.g. Debian maker resolve this? Does bin field works different from mine?

[SpacingBat3]

Also, injecting would probably simplify coexistence with recently introduced flagsFile option that is going to be usable in future release.

[obra]

Indeed, what I meant was to offer a way for the user provide a custom script to your builder to fully replace the default script. For our use case, just having a way to set custom flags might actually be enough. (and no worries about the response time - thank you for making something useful! I really appreciate it.)

…

On Thu, May 4, 2023, at 6:11 AM, SpacingBat3 wrote: Hi, sorry for the late response, I've been actually considering if I really want to allow for replacing the whole script rather than allow for injection into the existing one – the thing is, I want the script to be kept minimal but generic enough to guarantee similar results when executing any of the AppImages produced by my maker – after all, all of them are Electron apps. This means: • I want to use POSIX-compatible syntax for shell scripts (hence `#!/bin/sh`), giving the choice to people who use different shells who can work as POSIX shell, so whenever users use e.g. DASH, ZSH or BASH, they can use it to run my script (either when running in POSIX compatibility mode like in case of ZSH or normally if shell is already POSIX-compilant), therefore avoiding the dependence on one specific shell. I would prefer for developers depending on my maker not to switch to another shell, an assumption that everyone uses BASH on Linux isn't always the best. • The implementation for finding Electron binary and executing it is generic enough to work for many applications, so in most cases if some application finds a better implementation it would be better to improve it at upstream so other apps can benefit from it. I saw your fork and since I saw you mostly need this for initializing Electron with custom flags based on OS, like using Wayland Native. I think simply injecting the script would be enough for that task (you could use `set -- <args> "$@"` to set custom command-line flags). Also I plan to mimic a bit the way how original Electron Forge makers work (at least *oddities* people might be used to or way you configure my maker) and I'm kinda curious how e.g. Debian maker resolve this? Does `bin` field works different from mine? — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALC2H7EQKIBTPETBMVNZ3XEOTGXANCNFSM6AAAAAAVZ5LT3E>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[SpacingBat3]

When we used electron-builder, they had a hook in between building the content of the AppImage and the final packaging we could hook into.

@obra Electron Forge has hooks as well, forgot to mention that. And if you plan to use official makers (and probably most community-based ones) and make your configuration more global than specific to given maker, you probably should be using that instead. In your case (similar to what you've described), there's a postPackage hook you can use yourself – it happens after Electron Forge packs your app into ASAR (if configured to do so) and bundles it with Electron binary, but before you build anything (like Electron Forge maker).

I've been personally using hooks myself to implement features Forge didn't supported before or to mitigate bugs with some Forge's maker design, like producing Squirrel installers with the same name, making it unable to host on GitHub with the publisher when supporting multi-arch builds.

But as this maker is using the script by itself, I'll still plan to implement this feature, yet it might take a while as I'll be also ditching the shell script use if not really needed (I'll use symlinks instead, like Forge did). Here's a table that might illustrate the conditions maker will have to handle (includeFile is a non-definitife name for future property name):

	flagsFile === false	flagsFile === true
includeFile === false	Use symlink	Use shell script + .conf support.
includeFile === true	Use shell script + user overrides	Use shell script + .conf support + user overrides.