$HOME ends up hardcoded in shebangs

[probonopd]

Using this script, and then deleting the original AppDir, I get when I try to run the AppImage:

me@host:~$ ./squashfs-root/AppRun # Without existing WINEPREFIX overlay
bash: ./squashfs-root/AppRun: /home/me/AppDir/usr/conda/bin/python: bad interpreter: No such file or directory

/home/me/AppDir/ was the location of the AppDir at creation time. It should not be hardcoded, especially not in shebangs.

[TheAssassin]

Stuff in shebangs can't be trusted with this plugin. The best solution is to always write your own AppRun script, and hand it to linuxdeploy with --custom-apprun myscript.sh. I will probably add an example script somewhere in the repo soon.

[probonopd]

This is what I am doing now, but let's also keep in mind that the main payload app might call other scripts, in which case the custom AppRun cannot do much...

[TheAssassin]

You can't have "relative" paths in shebangs. The only thing we could do would be to remove all shebangs and force you to use a script anyway.

[probonopd]

You can't have "relative" paths in shebangs.

Are you sure about this? Let's play around with variations of

#!/usr/bin/env readlink -f ...

[probonopd]

https://stackoverflow.com/a/33225083 recommends

#!/usr/bin/awk BEGIN{a=ARGV[1];sub(/[a-z_.]+$/,"python",a);system(a"\t"ARGV[1])}

[TheAssassin]

The first solution doesn't work as we don't set PATH.

The second one is super ugly, and noone really knows whether that'd work reliably... (there's different implementations of AWK)... but it might go in the right direction...

[probonopd]

The awk solution works, but is relative to the called symlink rather than relative to the symlinked file, which makes a difference for AppRun.

[probonopd]

noone really knows whether that'd work reliably

Which is still better than a hardcoded path which everyone knows with certainty will not work ;-)

[TheAssassin]

You probably haven't tested on all X distros against all implementations of awk, did you? Also, who says awk might be installed? It's not part of a default installation.

Again: my "solution" is to remove all shebangs.

[probonopd]

Again: my "solution" is to remove all shebangs.

What happens if Python script A tries to exec Python script B?

[TheAssassin]

Why should they not do it in Python directly? You shouldn't rely on such stuff. Also, why these virtual questions? You can't auto fix this in a good way, I guess we've come to this conclusion. If you find a solution, please feel free to send a PR. But right now, I don't see any good ways.

[probonopd]

The awk above is better than leaving a hardcoded string that never works, can we agree on that?

[TheAssassin]

No, because that string would a) have to be generated for every file in every directory relative to the Python interpreter. It's a huge mess!

[TheAssassin]

@probonopd are you willing to send a PR implementing your awk solution? I think the build runtime overhead is well invested if it can work in some scenarios.

[probonopd]

Right now I cant`do it due to lack of time, maybe when I next time run into the issue... or maybe someone else does it in the meantime. How does @niess handle this type of thing in https://github.com/niess/linuxdeploy-plugin-python?

[niess]

@probonopd: following the install of python and extra packages (using pip), the plugin script looks for any Python script under /bin and replaces its absolute shebang with a relative one (see L179). I use the exec trick e.g. as indicated in the 1st answer of this S.O. question.

I have to say that I didn't investigate the pros and cons of the various options discussed there. I implemented the exec trick some time ago, after some googling, and didn't know about the other solutions at that time. It seems to work fine so far.

[TheAssassin]

@niess mind to send us a PR? I mean, as long as only the shebang is modified, it won't break anything. The recommended way is to avoid relying on shebangs, though.