sh + love bundled in one file - is this intended behaviour?

[reverent.lapwing]

Hi everyone,

I've been playing around with self-extracting starting script (Linux) and discovered that if I append the .love file to a script like this:

Code: Select all

    #!/bin/sh
    exec love "${0}" "$@" && exit
    # here goes the .love contents
    ...

I can run a game just by running this script. I tested this only on Manjaro (I doubt that matters) and with love-11.5. Is this an intended behaviour? And if not, can we make this a documented feature going forward? Windows distribution already doesn't use .love files and having a single executable file containing the game instead of a separate launcher script and a .love file is simply nicer.

Steps to reproduce:

1. Create an executable script "launcher" (empty line at the end is important):

Code: Select all

    #!/bin/sh
    exec love "${0}" "$@" && exit
    # here goes the .love contents

2. Create a .love file as normal
3. cat *.love >> launcher

[slime]

If you just have a runnable .love file without also providing LÖVE itself as well, then you don't have something you can distribute on its own because it relies on the user having LÖVE installed separately themselves in a place where the 'love' command can run from anywhere.

A typical way to distribute your game on Linux is to rebundle the AppImage with your game included (there are instructions on the wiki for that).

[BrotSagtMist]

Is your linux broken? .love files can just be clicked on.
Your solution basically just ads extra unnecessary steps.
I mean you could also stuff the rest of löve in that sh too but that is just a weird form of an appimage.

[dusoft]

I think he was thinking for distributing, but then the sh script would have to check for existence of love. And that brings us to AppImage (or FlatPak or Snap)...

[reverent.lapwing]

If you just have a runnable .love file without also providing LÖVE itself as well, then you don't have something you can distribute on its own because it relies on the user having LÖVE installed separately themselves in a place where the 'love' command can run from anywhere.

A typical way to distribute your game on Linux is to rebundle the AppImage with your game included (there are instructions on the wiki for that).

I think she was thinking for distributing, but then the sh script would have to check for existence of love. And that brings us to AppImage (or FlatPak or Snap)...

The game needs to be packaged into Aur/Deb/Rpm either way, it doesn't make sense to distribute Linux software any other way. The dependency should be resolved by a package manager. It's just a difference between having a script that launches a love file (like the Debian packaging policy for Love games) and packaging those two files together.

Is your linux broken? .love files can just be clicked on.
Your solution basically just ads extra unnecessary steps.
I mean you could also stuff the rest of löve in that sh too but that is just a weird form of an appimage.

When you double-click on .love file in file browser, the system runs a command under the hood to start it. You cannot actually execute .love file and it's usually expected for Linux packages containing programs to provide an executable. Again, Debian packaging policy requires it.

[reverent.lapwing]

I mean you could also stuff the rest of löve in that sh too but that is just a weird form of an appimage.

Sorry for double posting, I didn't fully parse that sentence.

No, that's completely different. All that happens in my post is that Love executable ignores a piece of .love file that doesn't appear to be in zip file format, so you can put a piece of shell script in there. I don't know how you could do that with love executable itself, since the system will not recognize it as an ELF executable unless it's an ELF executable and nothing else (ELF is the equivalent of EXE on Windows).

[BrotSagtMist]

Yes it runs xdg-open which in return runs love %f.
I think you fundamentally misunderstood things here.
.love is just a zip. Löve just calles unzip on everything you throw onto it.
It discards anything before the actual zip header, that way you can still double click fused images, or rather you could start fused games with either themself or with the locally installed version of Löve.
And no, no Linux requires executables in their packages, quite the opposite, games and their runtimes are usually in different packages.
Löve is in the debian repo already so putting stuff in a .deb should be a piece of cake.

Sidenot: if you want to see more about this "appending stuff to a sh" method i recomment finding "sakis 3g script".

[pgimeno]

At the end of the file, zip files always have a directory followed by a footer. The footer indicates where to find the directory, relative to the end of the file, and the directory can also find the actual compressed files in the same way.

So, you can append a zip file to any file, and the result will still be unzippable. Löve is just working as an unzipper in this case.

For Löve files that are not actually in zip format (e.g. 7-zip), that magic doesn't work. I haven't tried, but I doubt you can fuse the executable and a 7-zip format Löve file, even if you can run the .love file from the command line.

[BrotSagtMist]

I just tried and yes it doesnt.
Shit, good comment.
I was actually relying heavily on 7z in my folder structure to deal with tons of symlinks.
Havnt had limitations on my radar.

[reverent.lapwing]

At the end of the file, zip files always have a directory followed by a footer. The footer indicates where to find the directory, relative to the end of the file, and the directory can also find the actual compressed files in the same way.

So, you can append a zip file to any file, and the result will still be unzippable. Löve is just working as an unzipper in this case.

Thank you, I had no idea zip files work this way. That would answer my doubt about this being an intended behaviour.

And no, no Linux requires executables in their packages, quite the opposite, games and their runtimes are usually in different packages.

I can concede on that point, I have far more experience with using and packaging apps and tools than with packaging games.