How to correctly run AppImage and other programs in /opt?

I am under the impression that it is a good ideal to install applications to /opt

Therefore, whenever I download a program I place it in /opt. However, some of these are AppImages and some of them are folders.

However, now to run one of those applications, I have to run /opt/pathtoapp/ from a terminal prompt - and usually with sudo because of the app location in opt.

Is there an easy way to make a desktop icon, add it to my system and make the application be recognized as a native application (like to open other files with) and run without sudo privileges when it is located in /opt?

Solution 1:

appimaged is an optional daemon that watches certain locations for AppImages and if it detects some, registers them with the system, so that they show up in the menu, have their icons show up, MIME types associated, etc. It also unregisters AppImages again from the system if they are deleted.

appimaged will register the AppImages in with your system from the following places:

• $HOME/Downloads (or its localized equivalent, as determined by G_USER_DIRECTORY_DOWNLOAD in glib)
• $HOME/.local/bin
• $HOME/bin
• $HOME/Applications
• /Applications
• [any mounted partition]/Applications
• /opt
• /usr/local/bin

https://github.com/AppImage/appimaged#monitored-directories

Solution 2:

There are few things you have to do with the externally-installed application for it to be "integrated" into your system. But first let's clarify installation directories:

Installation directories

/opt is a folder for system-wide storing and installation of externally installed applications.

~/.local/ is a set of folders for your-user-only storing and installation of the same apps.

Note: ~ means $HOME var, which is usually /home/your_username - your home folder

Sudo problems

There should NOT be a need to sudo the application, where ever could it be saved unless the app itself needs root privileges. Check the following:

1. If the file permissions of the app file(s) are OK:

   You can learn about Linux's permission system all around the internet. One tutorial is here: https://www.digitalocean.com/community/tutorials/an-introduction-to-linux-permissions

   The file should have (when ls -l [filename]) these permissions:

   775 = rwxrwxr-x

   Beware: Changing permission can be dangerous.

   If it's not, just: chmod 775 filename

2. If all folders containing this app's file(s) have correct permissions:

   775 = rwxrwxr-x

   If not, just chmod 775 folder

3. If the app doesn't try to access any files with non-matching permissions:

   This may be harder to check, but usually, you can just enable debugging mode on the app with (for example) -v option (differs from app to app - you can sometimes find out by --help or in man or info pages) and then see the errors the app prints out.

   Note: You can ask on forums (like here) about the app, that's causing the problems. Remember to provide:

   1. What IS the problem
   2. What is the app
   3. LOGS - Really important. These help people to know what is causing the problem.

   (Warning: With this question, you didn't show us what makes you use sudo on those apps! If none of these methods work, it WILL be certainly because WE do NOT know what is happening in your computer!)

DE "integration"

DE = Desktop Environment

App launchers are saved in file(s) (like everything on Linux).

Get more info on AppName.desktop files: https://developer.gnome.org/integration-guide/stable/desktop-files.html.en and https://wiki.archlinux.org/index.php/Desktop_entries

On most Linux distros (including Ubuntu), AppName.desktop files are used. If the app you are using doesn't provide these, you can make yourself one (and not just for apps).

Just put this into a file named AnyNameYouWantHere.desktop file:

[Desktop Entry]
Type=Application
Name=Total Legit App Name
Comment=Lorem ipsum Comment Magic
Icon=/path/to/icon.png
Exec=/home/your_username/.local/share/AppName/AppImage
Terminal=false
Categories=game

Note: The exec doesn't have to be an AppImage, it just has to be executable. Check with your app. Also, check permissions as in the chapter above (775).

Then run:

xdg-desktop-menu install --novendor AnyNameYouWantHere.desktop

You can as well provide --mode option: (according to the man page of xdg-desktop-menu)

--mode mode

mode can be user or system. In user mode, the file is (un)installed for the current user only. In system mode the file is (un)installed for all users on the system. Usually, only root is allowed to install in system mode.

The default is to use system mode when called by root and to use user

You can now delete the file - xdg-desktop-menu has copied it to its own location.

Note: Managing apps that are used as default should be in system options.

Shell integration

To run the app from the shell without the need to supply its whole location, you have to add it to your PATH.

What is a PATH, you might ask...

$PATH is a variable in your shell, that tells bash, dash, zsh, or any other shell where are apps saved. On most systems it's going to have something like this in it:

$PATH=/bin:/usr/bin

Note: PATH is also available on most systems. Even MS W*ndows has an equivalent of it.

This tells your shell that when you put an app name in it, it should look for it in these locations.

Where to then save the app?

If it's system-wide installed:

Just link it into the /usr/bin directory:

ln -s /opt/amazingapp/AppImage /usr/bin/

Note: You should link it symbolically and absolutely, not relatively. (It depends on the type of usage.) More info about links here: https://en.wikipedia.org/wiki/Ln_(Unix) and here: https://en.wikipedia.org/wiki/Symbolic_link

If it's user installed:

Again link it as above, but this time into /home/your_username/.local/bin, then add /home/your_username/.local/bin in to your PATH, if it isn't already in there. (Most info HERE: https://unix.stackexchange.com/a/26059/316299 ) You can test that after you linked the program, by closing and opening the shell again, and trying the full name of the app.