Initially the two projects traveled in parallel to each other, until version 5, in which the codes merged. However, depending on whether it is installed permanently using a specific method ("AM") or downloaded portablely ("AppMan", if renamed "appman") the two CLIs work slightly differently.

In short:

• "AM" applies system-wide programs integration (for all users), i.e. installs programs in the /opt directory (see Linux Standard Base), the launchers instead are installed in /usr/share/applications (or /usr/local/share/applications if the distribution is "immutable") with the "AM-" suffix and the links are placed in /usr/local/bin or /usr/local/games. To manage programs system wide, AM needs to be installed in /opt/am as "APP-MANAGER" with a /usr/local/bin/am as a symlink (see https://github.com/ivan-hc/AM#installation);
• "AppMan", on the other hand, works in a portable way and allows you to install and manage the same applications locally, in your "$HOME" directory, and without root privileges. However, it is important that it is renamed to appman to work (see https://github.com/ivan-hc/AppMan#installation)

NOTE, "AM" can be set to work like "AppMan" by enabling an alias provided with the command "am --user".

To be more detailed, here is an overview of how apps are installed by "AM" and "AppMan"

Where $PROGRAM is the application we're going to install:

• "AM" (ie the am command) installs programs system-wide. "AM" requires the sudo privileges but only to install and remove the app, all the other commands can be executed as a normal user. This allows multiple users of the same system to be able to use the same installed applications. This is what an installation script installs with "AM":

  /opt/$PROGRAM/
  /opt/$PROGRAM/$PROGRAM
  /opt/$PROGRAM/AM-updater
  /opt/$PROGRAM/remove
  /opt/$PROGRAM/icons/$ICON-NAME
  /usr/local/bin/$PROGRAM
  /usr/share/applications/AM-$PROGRAM.desktop
  

If the distro is immutable instead, the path of the launcher (the last line above) will change like this:

  /usr/local/share/applications/AM-$PROGRAM.desktop

Since version 5.1 the installation process have introduced a check to find read-only filesystems (grep "[[:space:]]ro[[:space:],]" /proc/mounts), if there are mountpoints like this, your distro may be an immutable one, so an /usr/local/share/applications directory will be created and the installation script will be patched to redirect the installation of launchers in that path to solve the issue.

• "AppMan" (ie the appman command) instead does not need root privileges to work, it allows you to choose where to install your applications into your $HOME directory. AppMan is also usable as a portable app (i.e. you can download and place it wherever you want) and it is able to update itself, anywhere! At first start it will ask you where to install the apps and it will create the directory for you (the configuration file is in ~/.config/appman). For example, suppose you want install everything in "Applicazioni" (the italian of "applications"), this is the structure of what an installation scripts installs with "AppMan" instead:

  ~/Applicazioni/$PROGRAM/
  ~/Applicazioni/$PROGRAM/$PROGRAM
  ~/Applicazioni/$PROGRAM/AM-updater
  ~/Applicazioni/$PROGRAM/remove
  ~/Applicazioni/$PROGRAM/icons/$ICON-NAME
  ~/.local/bin/$PROGRAM
  ~/.local/share/applications/AM-$PROGRAM.desktop
  

For everything else, the controls and operation are always the same for both command line tools. The only thing that changes is that the installation scripts are written only for "AM", while "AppMan" uses the same scripts and includes commands that can modify them to make them work locally during the installation process.

If you usa "AM" and have the needing of installing apps at system level and locally, use the option --user that allows you to create an alias to install and manage apps in your $HOME folder. When executing the am --user command you will be suggested an alias to use temporarily or if you want you can add it in your ~/.bashrc to make it permanent. "AppMan" will be used while still using the usual am command.

The --user option does not immediately enable "AppMan Mode", instead it will show you an alias to use temporarily in the current session or to add to your ~/.bashrc to make it permanent:

alias am=/opt/am/appman

AppMan is downloaded to the AM's installation folder, but without affecting the existing installation.

NOTE: using AM with the --user option enabled and the alias for AppMan, "sudo" allows normal use of AM, absence allows use of AppMan.

"AM"/"AppMan" installs/removes/updates/manages only standalone programs, ie those programs that can be run from a single directory in which they are contained (where $PROGRAM is the name of the application, "AM" installs them always into a dedicated folder named /opt/$PROGRAM, while "AppMan" lets you choose to install them in a dedicated directory in your $HOME).

The "AM" repository aims to be a reference point where you can download all the AppImage packages scattered around the web, otherwise unobtainable, as you would expect from any package manager, through specific installation scripts for each application, as happens with the AUR PKGBUILDs, on Arch Linux. "AM" is intended to be a kind of Arch User Repository (AUR) of AppImage packages, providing them a home to stay. An both "AM" and "AppMan" are the key of this home. Visit...

https://portable-linux-apps.github.io

... for more!

STANDALONE PROGRAMS

The programs are taken:

• from official sources (see Firefox, Thunderbird, Blender, NodeJS, Chromium Latest, Platform Tools...);
• extracted from official .deb/tar/zip packages;
• from the repositories and official sites of individual developers.

APPIMAGES

The vast majority of scripts target AppImage packages:

• from official sources (if the upstream developers provide them);
• from AppImage recipes to be compiled on-the-fly with pkg2appimage and appimagetool;
• from unofficial third-party developers, but only if an official release is not available.

You can consult basic information, links to sites and sources used through the related am -a $PROGRAM command.

FIREFOX PROFILES

You even create Firefox profiles to run as webapps, the ones with suffix "ffwa-" in the apps list.

THIRD-PARTY LIBRARIES

From version 5.8 it is also possible to install third-party libraries if they are not provided in your distribution's repositories.

The full list is here.

To update all the programs and "AM" itself, just run the command (without sudo):

am -u

To update only the programs:

am -u --apps

To update just one program:

am -u $PROGRAM

Here are the ways in which the updates will be made:

• Updateable AppImages can rely on an appimageupdatetool-based "updater" or on their external zsync file (if provided by the developer);
• Non-updateable AppImages and other standalone programs will be replaced only with a more recent version if available, this will be taken by comparing the installed version with the one available on the source (using "curl", "grep" and "cat"), the same is for some AppImages created with pkg2appimage and appimagetool;
• Fixed versions will be listed with their build number (e.g. $PROGRAM-1.1.1). Note that most of the programs are updateable, so fixed versions will only be added upon request (or if it is really difficult to find a right wget/curl command to download the latest version).

NOTE, with "AM", during the first installation, the main user ($currentuser) will take the necessary permissions on each /opt/$PROGRAM directory, in this way all updates will be automatic and without root permissions.

In this video I'll show you how to test an update on "Avidemux" using "AM" (I use my custom AppImage I have built from "deb-multimedia", for my use case, but don't worry, the official Avidemux AppImage is also available on this repository). Firefox, on the other hand, is not affected by this management, as it can be updated automatically:

https://github.com/ivan-hc/AM/assets/88724353/7e1845e7-bd02-495a-a1b5-735867a765d1

Each program is installed through a dedicated script, and all these scripts are listed in the "repository" and divided by architecture.

NOTE that currently my work focuses on applications for x86_64 architecture, but it is possible to extend "AM" to all other available architectures.

Click on the link of your architecture to see the list of all the apps available on this repository:

• x86_64
• i686
• aarch64

If you are interested, you can deliberately join this project to improve the lists above.

• There are many other AppImage managers around, and almost all of them support their database on appimagehub or other official AppImage resources, but the big problem is at the base of the compilation of these packages, being very often without an integrated update system. Furthermore, AppImage is a format that many developers are abandoning in favor of Flatpak, also because there were no centralized repositories or software that managed its updates in a universal way... at least until the invention of the first draft of AppMan;
• With "AM"/"AppMan" each installed program has its own script (AM-updater) that compares the installed version with the one available in the sources or uses official tools to update the AppImages (see above), there is support for multiple architectures (including i686 and aarch64) and anyone can create a script to install that particular program (if available for its architecture).

Listed below are optional dependencies that are needed only by some programs

Don't worry, if you come across one of these programs, a message will warn you that the program cannot be installed, skipping the installation process just for that script:

• "binutils", contains a series of basic commands, including "ar" which extracts .deb packages (which are very few here);
• "unzip", to extract .zip packages;
• "tar", to extract .tar* packages;
• "zsync", about 10% of AppImages depend on this to be updated.

OPTIONS

(standard, for both "AM" and "APPMAN")

-a, about

SYNOPSIS:

-a {PROGRAM}

DESCRIPTION: Shows more info about one or more apps, all the pages are downloaded from https://portable-linux-apps.github.io

-b, backup

SYNOPSIS:

-b {PROGRAM}

DESCRIPTION: Save the current version of one or more apps, each snapshot is stored into a dedicated directory, under $HOME/.am-snapshots/$PROGRAM

To restore the snapshots see the "-o" option.

-c, clean

SYNOPSIS:

-c

DESCRIPTION: Removes all the unnecessary files and folders.

-d, download

SYNOPSIS:

-d {PROGRAM}

-d --convert {PROGRAM}

DESCRIPTION: Download one or more installation scripts to your desktop. With the option "--convert" its converted to a standalone local installer, but AM requires AppMan to be installed to add custom directory settings.

-f, files

SYNOPSIS:

-f

-f --byname

-f --less

DESCRIPTION: Shows the list of all installed programs, with sizes. By default apps are sorted by size, use "--byname" to sort by name. With the option "--less" it shows only the number of installed apps.

-h, help

SYNOPSIS:

-h

DESCRIPTION: Prints this message.

-H, --home

SYNOPSIS:

-H {PROGRAM}

DESCRIPTION: Set a dedicated $HOME directory for one or more AppImages.

-i, install

SYNOPSIS:

-i {PROGRAM}

-i --debug {PROGRAM}

-i --force-latest {PROGRAM}

DESCRIPTION: Install one or more programs or libraries from the list. With the "--debug" option you can see log messages to debug the script. For more details on "--force-latest", see the dedicated option, below.

-l, list

SYNOPSIS:

-l

DESCRIPTION: Shows the list of all the apps available in the repository.

-o, overwrite

SYNOPSIS:

-o {PROGRAM}

DESCRIPTION: Overwrite the existing version of the app with a snapshot saved previously (see the option "-b", above).

-q, query

SYNOPSIS:

-q {KEYWORD}

DESCRIPTION: Can be used to search for keywords and terms in the list of available applications packages to display matches. This can be useful if you are looking for applications having a specific feature.

-r, remove

SYNOPSIS:

-r {PROGRAM}

DESCRIPTION: Removes one or more apps, requires confirmation.

-R

SYNOPSIS:

-R {PROGRAM}

DESCRIPTION: Removes one or more apps without asking.

-s, sync

SYNOPSIS:

-s

DESCRIPTION: Updates this script to the latest version hosted.

-t, template

SYNOPSIS:

-t {PROGRAM}

DESCRIPTION: This option allows you to generate a custom script from a list of different templates that may be vary according to the kind of app you want to upload to the "AM" repo, and the source where it is available. You can install it using the am test /path/to/your-script command.

-u, -U, update

SYNOPSIS:

-u

-u apps

-u {PROGRAM}

DESCRIPTION: Update all the apps (and "am" itself) or just one. If you add the "--apps" suboption you only update apps.

-v, version

SYNOPSIS:

-v

DESCRIPTION: Shows the version.

--disable-completion

SYNOPSIS:

--disable-completion

DESCRIPTION: Disable bash-completion.

--enable-completion

SYNOPSIS:

--enable-completion

DESCRIPTION: Enable bash-completion to complete a keyword with the "TAB" key, using the names of all installable applications available.

--firejail, --sandbox

SYNOPSIS:

--firejail {PROGRAM}

DESCRIPTION: Run an AppImage in a sandbox using Firejail.

--force-latest

SYNOPSIS:

--force-latest {PROGRAM}

-i --force-latest {PROGRAM}

DESCRIPTION: Downgrades an installed app from pre-release to "latest". This can be used with "-i" to force the installation of apps from "latest". Many scripts point to "releases" to find the latest build for GNU/Linux if the developer has not uploaded one in "latest".

--launcher

SYNOPSIS:

--launcher /path/to/${APPIMAGE}

DESCRIPTION: Embed one or more local AppImages in the applications menu. I suggest dragging the files into the terminal to get the desired effect. Launchers are located in ~/.local/share/applications/AppImages by default.

--rollback

SYNOPSIS:

--rollback {PROGRAM}

DESCRIPTION: Download an older or specific version of the software you are interested in (only works with Github).

apikey

SYNOPSIS:

apikey {Github Token}

apikey delete

DESCRIPTION: Get unlimited access to https://api.github.com using your personal access tokens. The configuration file named "ghapikey.txt" will be saved in '$AMPATH' . Use the command "'$AMCLI' apikey delete/del/remove" to remove the file.

dev, devmode

SYNOPSIS:

dev off

dev on

DESCRIPTION: View the installer output during installation, use "on". It can be disabled with "off" or with the "-s" and "-u" options.

lock

SYNOPSIS:

lock {PROGRAM}

DESCRIPTION: Lock the selected app to the current version installed, this only works if exists a dedicated "AM-updater" installed with the app.

neodb

SYNOPSIS:

neodb

neodb --silent

DESCRIPTION: Add third-party repos to extend the existing database. Use "--silent" to hide messages about third-party repos in use.

newrepo

SYNOPSIS:

newrepo {URL}

newrepo off

newrepo on

DESCRIPTION: Set the variable "$AMREPO" to a new custom repository. Use "off" to restore the default one or overwrite it with a new one.

nolibfuse

SYNOPSIS:

nolibfuse {PROGRAM}

DESCRIPTION: Convert an installed Type2 AppImage to a Type3 AppImage. Type3 AppImages does not require libfuse2 installed. Only AppImages updatable with "zsync" can be updated keeping this format. Others will be replaced with the one provided from the upstream.

unlock

SYNOPSIS:

unlock {PROGRAM}

DESCRIPTION: Unlock updates for the selected program. This option nulls the option "lock" (see above).

EXTRA OPTIONS

--user, appman (only available for "AM")

SYNOPSIS:

--user

DESCRIPTION: Run "AM" as an unprivileged user making it act as "AppMan".

Since 2.3.1 release "AM" has its inbuilt bash completion script that can be enabled using the following command:

am --enable-completion

This will ceate a bash completion script in /etc/bash_completion.d named am-completion.sh needed to complete a keyword with the TAB key using the names of all the main options and the name of the scripts of all the applications available in the "AM" repository. To disable bash completion (and to remove the /etc/bash_completion.d/am-completion.sh script):

am --disable-completion

Here you are a video on how to disable/enable bash completion in "AM":

https://user-images.githubusercontent.com/88724353/155971864-783c098c-e696-47b5-aaa8-85dab6ab3b46.mp4

A more detailed guide on how to create your own bash completion script for your project is available here.

Since 2.6.1 release, "AM" supports snapshots of all installed applications. A selected program can be copied locally into your home folder.

Here you are a video on how to backup/restore works in "AM":

https://user-images.githubusercontent.com/88724353/157094646-0e29ddbe-6cb7-4880-8414-110db071e617.mp4

• option -b or backup creates the snapshot, usage:

  am -b $PROGRAM
  

• option -o or overwrite allows you to roll back to a previous version of the program. Usage:

  am -o $PROGRAM
  

All the snapshots are stored into an hidden /home/$USER/.am-snapshots folder containing other subfolders, each one has the name of the programs you've done a backup before. Each snapshot is named with the date and time you have done the backup. To restore the application to a previous version, copy/paste the name of the snapshot when the -o option will prompt it.

• To update a program without "am":

/opt/$PROGRAM/AM-updater

Note that this works only if the program has a /opt/$PROGRAM/AM-updater script, other programs like Firefox and Thunderbird are auto-updatable.

• To uninstall a program without "am":

sudo /opt/$PROGRAM/remove

From version 4.4 it is possible to directly select from a list of URLs the version of the app that interests you most from the main source. Use the --rollback option in this mode:

am --rollback ${PROGRAM}

This only works with the apps hosted on Github.

Since version 6.1 it is possible to convert old Type2 AppImages (dependent on libfuse2) to Type3 using the option nolibfuse.

am nolibfuse ${PROGRAM}

First the selected program type is checked, if it is a Type2 AppImage, it will be extracted and repackaged using the new version of appimagetool from https://github.com/probonopd/go-appimage :

• If the installed AppImage can be updated via zsync, the update will take place while maintaining the status of Type3 AppImage;
• On the contrary, if the update occurs through "comparison" of versions, the converted AppImage will be replaced by the upstream version, which could still be Type2. But from version 6.1.1 the command is added within the application's AM-updater script, so as to automatically start the conversion at each update (prolonging the update time, depending on the size of the AppImage). I suggest anyone to contact the developers to update the packaging method of their AppImage!

NOTE, the conversion is not always successful, a lot depends on how the program is packaged. The conversion occurs in two steps:

• if in the first case it succeeds without problems, the package will be repackaged as it was, but of Type 3 (and the AM-updater script will be patched if a .zsync file doesn't exist);
• if the script encounters problems (due to Appstream validation), it will attempt to delete the contents of the /usr/share/metainfo directory inside the AppImage, as a workaround (which will probably make updates via zsync unusable);
• if this step does not succeed either, the process will end with an error and the AppImage will remain Type2.

See the video:

https://github.com/ivan-hc/AM/assets/88724353/8b45d2c2-d2da-4a07-8b43-0cd77ffcb7cc

Since version 4.4.2 you can use the --launcher option to integrate your local AppImage packages by simply dragging and dropping them into the terminal (see video).

https://github.com/ivan-hc/AM/assets/88724353/c4b889f4-8504-4853-8918-44d52084fe6c

Since version 5.3 you can use the --firejail option to run AppImages using a sandbox (requires Firejail installed on the host).

At first start a copy of /etc/firejail/default.profile will be saved in your application's directory, so you're free to launch the AppImage once using the default Firejail profile (option 1) or the custom one (2), you can also patch the .desktop files (if available) to in sandbox-mode always (options 3 and 4). You can handle the custom firejail.profile file of the app using vim or nano using the option 5 (the first selection is vim).

Options 1, 2 and 5 are continuous to let you edit the file and test your changes immediately. Press any key to exit.

NOTE: once patched the .desktop files (options 3 and 4), they will be placed in ~/.local/share/applications, this means that if you have installed apps using AppMan, the original launchers will be overwrited.

"AM"/"AppMan" has a -t option (or template) with which you can get a script to customize according to your needs. With this option, you can quickly create scripts to download existing programs or even create AppImage or AppDirs through tools such as appimagetool and pkg2appimage.

The following video shows how to create and test an AppImage of "Abiword" from Debian Unstable repository with a custom AppRun (option 5):

https://user-images.githubusercontent.com/88724353/150619523-a45455f6-a656-4753-93fe-aa99babc1083.mp4

The currently available templates are stored here.

A wiki is also available, here I will try to explain the installation script's workflow for a program to be better managed by "AM", trying to use a language that is as simple and elementary as possible.

Each script is written exclusively for "AM" and is structured in such a way that even "AppMan" can modify it to manage programs locally.

We can divide the stages of an installation's process as follows:

• Step 1: create the main directory in /opt, as already suggested by the Linux Standard Base (LSB);
• Step 2: create the "remove" script, needed to uninstall averything (this must be the first one to be created, in order to quickly resolve any aborted/brocken installations using the -r option);
• Step 3: download the program and/or compile the program (this operation varies depending on how the program is distributed);
• Step 4: link to a $PATH (usually /usr/local/bin, but also /usr/bin, /usr/games or /usr/local/games);
• Step 5: the "AM updater" script, which is a kind of "copy" of step "3" (see above) that may include options to recognize newer versions of the program. NOTE that if you intend to create a script for the fixed version of a program, you can also skip this step;
• Step 6: launchers and icons. Note that if you intend to create a script for a command line utility, you can also skip this step;
• Step 7: change the permissions in the program folder, so you can use the update function (step 5) without using "sudo" privileges
• Step 8 (optional): your signature

The most difficult step to overcome is certainly the number "3", given the great variety of methods in which authors distribute their software, while all the other steps are much easier to overcome.

To install and test your own script, use the command am -i /path/to/your-script or appman -i /path/to/your-script depending on your CLI

From version 6.4, "AM"/"AppMan" can be extended by adding new application databases using a configuration file named "neodb".

For more details, see the full guide at https://github.com/ivan-hc/neodb

Use the -a option and go to the developer's site to report the problem. The task of "AM" is solely to install / remove / update the applications managed by it. Problems related to the failure of an installed program or any related bugs are attributable solely to its developers.

There can be many reasons:

• check your internet connection;
• if the app is hosted on github.com, you have probably exceeded the hourly limit of API calls;
• the referring link may have been changed, try the --rollback option;
• the reference site has changed, report any changes at https://github.com/ivan-hc/AM/issues

If by running it in the terminal you get an error message about "FUSE" or "libfuse"/"libfuse2" missing, take a look at the official documentation:

https://docs.appimage.org/user-guide/troubleshooting/fuse.html

If your distro does not provide libfuse2, you can install it using the command:

am -i libfuse2

or

appman -i libfuse2

NOTE, in AppMan you still need to use your password (sudo) to install the library at system level, in /usr/local/lib

Alternatively you can use the "nolibfuse" option to "try" to convert old Type2 AppImages to Type3, so as not to depend on libfuse2. In most cases it works, but sometimes it can give errors, depending on how the package was manufactured.

However, I suggest contacting the upstream developers to convince them to upgrade their packages to Type3.

Before installing any application, try to know where it comes from first. This program provides you with two basic options for this purpose:

• Option -a or about (medium safety), allows you to read a short description and know the links from the pages of the site https://portable-linux-apps.github.io locally, however these links may be inaccurate due to continuous updates of the initial scripts (you can provide additional info yourself by modifying the pages of the site, here, it is also open source);
• Option -d or download (absolute safety), this allows you to get the installation script directly on your desktop, so you can read the mechanisms and how it performs the downloads from the sources (in most cases there is a header for each step that explains what the listed commands do).

“AM” and AppMan are just tools to easily install all listed programs, but what you choose to install is your complete responsibility. Use at your own risk!

Some developers insist on creating Appimages that create their own launcher on first launch (like WALC and OpenShot). If the official solution proposed here doesn't work, create a .home directory with the -H option, launch the app and accept the request. For example (with "AM"):

am -H walc
walc

Accept the integration request, the launcher will be saved in the walc.home directory located next to the AppImage file.

This is a choice I made as many developers have abandoned support for AppImage or GNU/Linux in general. My aim here is to introduce you to other developers' applications, then it's up to you to contact them, support them, help improve the software through forks and pull requests, opening issues and encouraging developers to keep the software in the format you prefer.

In case you are sure that the upstream developer will maintain the package for each stable release, you can fix this in several ways:

Method 1: Direct installation by combining -d and -i options

am -d $PROGRAM
sed -i 's#releases -O -#releases/latest -O -#g' $(xdg-user-dir DESKTOP)/$PROGRAM
am -i $(xdg-user-dir DESKTOP)/$PROGRAM

Method 2: "Downgrade" the installed app to "latest"

Use the option --force-latest to patch the AM-updater and perform the "update"/"downgrade":

am --force-latest $PROGRAM

or do it manually:

sed -i 's#releases -O -#releases/latest -O -#g' /opt/$PROGRAM/AM-updater
am -u $PROGRAM

With the arrival of Fedora 40 in April 2024, many users began to complain about the inability to download any application from github and the inability to update modules (see https://github.com/ivan-hc/AM/issues/496). This is because "wget" is no longer actively developed, and its successor "wget2" was not yet ready to take its place immediately. Yet the Fedora team decided to replace it anyway, causing quite a few problems for this project and many others that use api.github.com to function.

Attempts to add patches to avoid having dependencies like jq added and to rewrite all the scripts to promptly adapt them to more versatile solutions were in vain.

So I decided to host on this repository the "wget" binaries directly from Debian 12 (see here and here), and the installation scripts dedicated to them, for the x86_64 and aarch64 architectures and which use "wget2" to download the executable.

Run the command

am -i wget

NOTE, the binary is called from a script in /usr/local/bin that runs "wget" with the "--no-check-certificate" option. It's not the best of solutions, but it's enough to suppress this shortcoming while the compatibility issue between wget and wget2 will not be completely resolved.

The reasons may be two:

• the referring link may have been changed, try the --rollback option;
• the reference site has changed, report any changes at https://github.com/ivan-hc/AM/issues