Appimagekit: AppRun modifies PATH environment variable

[kropp]

In my case it works wrong, adding relative paths and thus altering path resolution in an unpredictable way.

What is the reason behind this? Is it possible to make it configurable without building own AppImage fork?

[TheAssassin]

AppRun sets up some, as we call them, safe defaults, which work fine for a majority of apps which rely on the kind of changes it applies before calling the actual application within the AppImage.

If you have a look at the implementation, you will see that AppRun calls chdir() and switches to the temporary mountpoint before calling the application. As long as this condition isn't modified (e.g., by calling chdir() within the target application), the relative paths work fine.
(By the way, just to clarify this, the chdir() isn't performed to get these relative paths to work, it had been implemented to support a hacky solution to make some applications which rely on hardcoded paths instead of resolving paths relative to their main binary, which obviously wouldn't work by default with AppImage's architecture.)

Maybe you should provide some more information on your application, though, e.g., a link to the source code and/or build recipe. Often, AppRun isn't necessary any more, as tools from the AppImage ecosystem like linuxdeployqt set up an application's binaries and its libraries in a way so the most relevant pieces of AppRun aren't necessary any more.

adding relative paths and thus altering path resolution in an unpredictable way.

Maybe post your PATH or entire environment then (in the latter case, please remove personal data before posting them here)?

By the way, you don't have to fork the entire project just because AppRun doesn't work for you. Just write your own! It's really easy, many projects use a simple shell script. Otherwise, you could just write and maintain your own AppRun.c. You're not the first one who has found AppRun doesn't work for them, and won't be the last one for sure. See e.g., https://github.com/AppImage/AppImageKit/issues/554 or https://github.com/AppImage/AppImageKit/issues/391.

The same bug is producing some annoying situations with applications taking paths as parameters, by the way, which sometimes interpret the paths relative to the mountpoint directory. File choosers' starting directory often is the mountpoint one, too. These are the cases which require a custom AppRun script, or alternatively these apps should have a look at linuxdeployqt which eliminates the need for AppRun.

If these last points are not a problem to you, we'd accept a PR making AppRun resolve the paths it appends to environment variables.

See also https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages#creating-an-appdir-manually on the role of AppRun.

[probonopd]

In my case it works wrong, adding relative paths and thus altering path resolution in an unpredictable way.

What is the reason behind this?

It's so that the bundled binaries inside the AppImage get preference over binaries on the host system. It's usually the desired behavior.

If you don't need this, you might be better off using your own launch script as the AppRun file, instead of the one from AppImageKit.

Is it possible to make it configurable without building own AppImage fork?

No. But as said above, I don't think you need to use our AppRun file but could use your own script instead.

[TheAssassin]

I'd like to reopen this issue, @probonopd. As you can read in my post, we should probably inject absolute paths rather than relative ones into the environment. We can keep track of this change in this issue.

[probonopd]

we should probably inject absolute paths rather than relative ones into the environment

What difference would it make?

[TheAssassin]

Some applications chdir() themselves. That's not good style, yes, but if they do, the binaries inside the AppImage are kind of "no longer reachable" to the payload application. Also, "explicit is better than implicit" (source).

[probonopd]

Some applications chdir() themselves. That's not good style, yes, but if they do, the binaries inside the AppImage are kind of "no longer reachable" to the payload application.

True. But just making the exported paths absolute won't help in cases where we have binary-patched hardcoded paths away.

Also, "explicit is better than implicit" (source).

That may be a good reason in itself.

[TheAssassin]

True. But just making the exported paths absolute won't help in cases where we have binary-patched hardcoded paths away.

That doesn't justify relative paths, though, it's more of a side note, I'd say. I'll send a PR.

[TheAssassin]

I'm confused. Looking at the code, it uses readlink() to resolve the path of /proc/self/exe to get the mounted directory's path, which happens to return an absolute path anyway. That path is prepended to all additions to the environment variables. I even went to testing this with a recent build of AppRun and env, and it worked absolutely fine.

@kropp I am closing this now as I can't even reproduce your issue. Feel free to reopen with the requested information, if the bug persists.

[probonopd]

@kropp can you give us an example to reproduce your issue please?

[kropp]

Thanks for the explanations, @TheAssassin @probonopd!
I checked this issue again with the newer AppRun and the paths are no longer relative. It resolved some of the problems we've seen.
However, following your suggestions, I decided to get rid of AppRun at all, and just put my launcher script there. AppImage is the only distribution format we support, so I don't have any compatibility issues with other formats.
It works now in a very predictable way.

Thanks again and keep up the good work!

[TheAssassin]

Thanks for the kind words, and thanks for the update. Good to see it works for you now! If you like our word, tell your friends!