AppImageKit
AppImageKit copied to clipboard
AppImage
Using /proc/self/cwd from within an appimage−d application
I'm frequently using /proc/self/cwd as the working directory because I don't like to start an application from a given directory, then having to navigate to the very same directory each time I open a file.
Intended Workflow: cd ~/long∕path/project1/ application& (press ^O, see all the files)
Unfortunately these applications start to use appimage so this stopped working. Instead I'll have to cope with the applications remembering the in-my-case-wrong directory in the open dialog. I'm not sure how to proceed from this point.
If $APPDIR and $APPIMAGE are set, then check the contents of $OWD instead. Those environment variables get set by the AppImage runtime.
I'd need to make the appimage execute e.g. 'ln -s "$OWD" /some/where in order to have access in the open-file-dialog. Not being the author I can't. Thus each time I'm using an application from a given directory, I have to change the directory in the open dialog - and again for the next application I'll use, then for the third ... then I'll change directory, do a different work and have to change the directory again.
(Unfortunately the file open dialogs seem to be written by people not using different directories for different files, especially for gtk based applications. Unfortunately you can't upgrade or patch developers)
I'd need to make the appimage execute e.g. 'ln -s "$OWD" /some/where in order to have access in the open-file-dialog. Not being the author I can't.
Why?
You can extract the AppImage, put in your custom AppRun script that does what you need, and pack the AppImage again using appimagetool. Or am I missing something?
Unfortunately you can't upgrade or patch developers
But possibly you can patch their code even if you don't have the source by using LD_PRELOAD and overriding some syscalls or functions... in case my suggestion from above is not sufficient.
Seems quite much like an edge case, and I don't see what we could do about it. Your workflow seems very, very unique.
If you have suggestions what we can do to fix your issues, please post them here. As long as they don't break anything, they should be viable to implement.
However I think your app is behaving wrongly. Perhaps it's using the ever-annoying AppRun.c from AppImageKit, that does funny stuff like force-changing the working directory?
We need more input. Let's start with, what app are you using, and can you share the AppImage for analysis?
I admit that my workflow may be unusual as I'm using console applications.
At first, I imagined opening a file descriptor to $CWD before chdir to the mountpoint. But which? Any one may be in use.
After some more thinking, maybe it would be useful to mount it to a given directory in a private namespace. E.g. /tmp/appimagecwd could be like /proc/self/cwd. I can imagine this to be useful for applications, too.
OTOH, using /tmp/ in that fashion seems to be insecure since this directory may be created by anyone.
I believe these applications do use AppRun.c. I'm currently using slic3r, Cura and FreeCAD, I'll post the links later.
Even though I must admit I don't know what exactly it is that you are doing, it sounds interesting. I am using "unusual" workflows myself, too :-)
Maybe you can give a working example (not using AppImage) and a non-working example (using AppImage) so that we can see exactly what you are doing, and what is not working.
I'm creating a part for my 3D printer. I'll create a directory for that part. From there, I start freecad and save the part to the current directory /proc/self/cwd. Then I'll open slic3r or cura, load the part and print it.
If I need to add a picture, I'll copy it to that directory and start gimp mypicture.foo.
If I need to use an appimage as 3 of 3 people offer them, I'll need to navigate to the base directory for my 3d models, navigate to the category and navigate to the actual part before being allowed to chose the file from the directory. If I'm exporting the stl from the freecad appimage, it's AFAIR using a separate directory.
At some time in the past most programs used to start in the current directory. I rather closed gimp and changed directory in the shell than using the dialog to do the same thing. Now every program tries to be helpful by changing the directory to the last used path - which is almost never what I intend. Blender is different by changing to ~.
Currently I'm working around this by ln -sfn "$PWD" ~/cwd before starting the programs.
I'm creating a part for my 3D printer. I'll create a directory for that part. From there, I start freecad and save the part to the current directory /proc/self/cwd. Then I'll open slic3r or cura, load the part and print it.
Why not store your files in $HOME?
So the issue is that from within an AppImage, /proc/self/cwd points to /tmp/.mount_...? Which AppImage(s)?
Most likely the AppRun binaries/scripts inside these AppImages are doing a chdir() before executing the main payload application. This is why /proc/self/cwd will (correctly) point to /tmp/.mount_.... The environment variable OWD (original working directory) main contain what you are interested in.
Reference: https://docs.appimage.org/packaging-guide/environment-variables.html#type-2-appimage-runtime
That's what I got, but that gets me nowhere as I can't use $OWD in the file dialog. Neither will freecad $myfile open a file while starting a program.
@7eggert what @probonopd means is, if his assumption is correct, then it's nothing to fix here, the AppImages in question are "misbehaving".
Simple example: the "misbehaving" AppImages do a cd before they run the main app, similar to:
> bash -c "cd /tmp && ls -al /proc/self/cwd"
[...] /proc/self/cwd -> /tmp
Our runtime doesn't this. But the AppImage startup scripts (called AppRun) might do. This used to be default for a while, some AppImages probably still do this. It's discouraged to do so, though.
@probonopd can you verify your claim perhaps? That'd clarify whether it's our issue or theirs. And it'd tell us whether we can ask @7eggert to step up to those projects and have their AppImages fixed, or whether we have to look into our own code.
Here's how to inspect what an AppImage is doing.
me@host:~$ wget -c https://dl.slic3r.org/linux/Slic3r-1.3.0-x86_64.AppImage
me@host:~$ chmod +x Slic3r-1.3.0-x86_64.AppImage
me@host:~$ ./Slic3r-1.3.0-x86_64.AppImage --appimage-extract AppRun
me@host:~$ cat squashfs-root/AppRun
In the case of this one, it is cd'ing but twice so it should end up in the original cwd although I am not sure why they are doing things this way.