Missing $APPIMAGE

[McPo]

7.14.1

Linux

I am attempting to obtain the original path to the AppImage that was launch. According to AppImage/AppImageKit#172 environment variables should be accessible to obtain this. (Although Im unsure if this project uses AppImageKit, in such a case this would then be a request to support a similar feature).

getApp() and getPath('exe') both return folders within the tmp directory.

The reason for this is that on OSX we store our userData within the .app folder such that trashing the application also removes the user data. We wish to implement a similar feature on Linux. Where the userData is set to the appImage directory.

Thanks,
Emmet

[develar]

5.4.2

Is outdated. Please latest version.

Where the userData is set to the appImage directory.

Are you sure? On macOS you cannot store user data inside .app folder because in this case app will be marked as corrupted. Ok, up to you. But — AppImage directory (mount point) exists only during app lifetime — on app exit will be unmounted. There is no .app directory like on macOS.

[McPo]

Same issue occurs on the latest.

Yeah, app is signed but not sandboxed. I haven't ran into any issues with OSX yet. Im also running with default GateKeeper settings. So seems like its fine.

I agree Im dubious about doing this myself. Which is why I was wanting to check out the level of effort to get it working on the other platforms too. I did suspect that you might not be able to write to the AppImage. I was initially using Deb packages, but as they were installed with root it obviously didn't play well, hence the move to AppImage. I never actually thought about hardcoding the path it to see if it would write (Ive just confirmed that it does not).

Error: ENOTDIR: not a directory

This feature could still prove useful if somebody wanted the next best thing, which would be to create a directory called AppName.UserData beside AppName.AppImage.

Thanks,
Emmet

[probonopd]

The relevant code is here in runtime.c - so if electron-builder uses a halfway recent AppImage runtime, then it should have it...

[develar]

Idea to write some data to mounted app directory — is BAD, bad idea. Mounted directory must be read-only due to security reasons.

@McPo Is APPIMAGE defined? Please try to use this env.

[McPo]

I get that writing to the AppImage is bad (and not possible), however it would still be useful to know of its location, such that somebody could create a directory beside it, etc.

APPIMAGE is not defined, hence I created the issue.

Infact no environment variables are defined (apart from NODE_ENV), it appears that something is swallowing them and are therefore not accessible via process.env.

The program is being launched by dragging the AppImage into the terminal window. I have also ran the unpacked version and it also only provides NODE_ENV. This may in fact be a general issue and not related to AppImage. Environment variables are available when running the development version but aren't in release., the only thing different than I can observe in release version is electron-builder is used. Im gonna try and reproduce this with a basic setup to rule out and any possible issues with my build system first.

throw Error(JSON.stringify(process.env));

Results in

Uncaught Exception:
Error: {"NODE_ENV":"production"}

[McPo]

This is a non-issue.
I built https://github.com/develar/onshape-desktop-shell, APPIMAGE and APPDIR exists.

There appears to be some issue with my build.

Apologies for wasting your time.

[develar]

@McPo Thanks for update. If you will find the cause, please post here, maybe electron-builder can spot it somehow.

Hint: maybe you use Object.assign(process.env) or somehow modify process.env?

[McPo]

I was using electron-react-boilerplate, which uses a webpack DefinePlugin. Which overrode the environment.

Ended up changing

new webpack.DefinePlugin({
            'process.env': {
                NODE_ENV: JSON.stringify('production')
            }
        })

to

new webpack.DefinePlugin({
            'process.env.NODE_ENV': '"production"'
        })

Cheers again.