Appimagekit: Find out the directory from where the appImage was ran

[jviotti]

Say I have my appImage in /opt/myapp.AppImage, but I open it using the terminal from say /home/jviotti/Desktop:

cd /home/jviotti/Desktop
/opt/myapp.AppImage

How can I get find /home/jviotti/Desktop, the place from where I ran the appImage from, from the app?

[probonopd]

$APPIMAGE isn't doing it?

[jviotti]

Hi @probonopd ,

$APPIMAGE returns the path to the AppImage. dirname $APPIMAGE returns the directory containing the AppImage. I'm looking for the directory from where the AppImage was called, when the user did so from the command line.

[probonopd]

CWD/PWD?

[jviotti]

I've tried that already, but it returns the mount point of the appImage (/tmp/.mount-XXXXX). Maybe we can propagate the current working directory, or expose it as another env var?

[probonopd]

Can you give some context of what you are trying to do? "." is not sufficient?

[jviotti]

Etcher opens a file selector dialog for the user to select the image. We've seen that for GNU/Linux applications that are opened from the command line, the file dialogs open with the directory from where the command was ran as a default.

Consider GIMP, for example. If I navigate to $HOME/Foo/Bar and call the gimp command from there, GIMP's dialogs will open on $HOME/Foo/Bar as a default.

We're trying to mimic the exact same behaviour. If I call the appImage from the command line when my current working directory is $HOME/Foo/Bar, then the dialog should open there by default.

This is proving to be a bit challenging since we have no way to get the current working directory before the appImage was called. Instead, once the appImage runs, the current working directory becomes the appImage mount-point.

[probonopd]

Are you using the binary AppRun or do you have your own AppRun? I think (although I didn't check) that by using your own AppRun you should get at the original cwd.

[jviotti]

I'm using the AppRun binary, but cwd doesn't seem to be inherited, but I might be running a too old version. I'll upgrade AppRun and AppImageAssistant and report back.

[probonopd]

No, you need to use your own script as AppRun. A bash script should do.

[probonopd]

Alternatively, comment out the chdir calls in https://github.com/probonopd/AppImageKit/bloacb/master/AppRun.c

[jviotti]

Ah, I misread the comment, sorry. I see, I think I have everything I need, so I'll close this ticket and re-open in case I encounter any other issues with it.

Thanks a lot!

[ericLemanissier]

@probonopd The same problem exists with the scribus appimage, and it is quite important because it is not able to handle properly relative file paths coming from the command line. You suggested to comment out the chdir calls in AppRun.c. If these chdir are not mandatory, why would any one keep them ? In other words, If I make a pull request to remove them from https://github.com/probonopd/AppImageKit/bloacb/master/AppRun.c would it be accepted ?

[probonopd]

@ericLemanissier see https://github.com/probonopd/AppImageKit/issues/137#issuecomment-212748323

Some (many!) binaries have paths in /usr hardcoded, and packaging such binaries inside an AppImage requires to binary-patch /usr to ././ which means "here". This only works if AppRun changes the working directory to the usr/ directory inside the AppImage before running the application.

If you are developing and compiling the payload application and its dependencies yourself, then you might not need this. But for the majority of existing software, you do.

So to answer your question, such a PR would not be accepted. A PR that would restore relative paths to absolute paths might (as in the link above). Or a PR that simply builds two versions of AppRun, one with and one without the chdir.

[jviotti]

@probonopd A bash AppRun works fine for us, but would you accept a pull request to expose a custom environment variable, like APPCWD (happy to discuss naming), with this value?

The addition of an env var means that we don't have to comment out the chdir calls, but still have a way to retrieve this information from the application, and have this feature coming from upstream instead of having to write a custom AppRun.

See https://github.com/probonopd/AppImageKit/pull/191

[probonopd]

Thanks jvotti, let's call it $OWD with O for Original.