Execute Bash and Yad gui script in AppImage.

[offternet]

Summary: Using appimagetool + shell scirpt + optional yad gui scirpting:

-- create shell script my-shell-script.sh
-- convert shell script to a c executable using bash command shc -f ./my-shell-script.sh.x
-- place compiled shell scipt in your XxxAppDir/usr/bin directory Along with the shell command executable files.
-- execute: ARCH=x86_64 appimagetool ./XxxAppDir
= my-shell-script-x86_64.AppImage

Detailed process:

1. Create standard AppImage AppDir - AppRun & app.desktop & app-desktop-icon.png & directory /usr/bin

2. Copy all executable files you want to run from shell script from within AppImage.
   This also includes the terminal command executables too, for example: bash, curl, fidsk, etc.
   Place all these files in the AppImage AppDir/usr/bin directory
   Compiled shell script goes in to AppImage /usr/bin directory too.

3. Convert your shell scirpt to c executable outside of the AppDir directories.
   Terminal --> user@group=$ shc -f ./my-shell-script.sh # produces filename - my-shell-script.sh.x

4. Your shell script command(s) do NOT need any path in front of the command.

5. AppRun and *.desktop file are normal configuration

6. Terminal --> user@group=$ ARCH=x86_64 appimagetool ./XxxAppDir

7. Test new AppImage file:
   Terminal --> user@group=$ ./my-shell-script-x86_64.AppImage

More Advanced use also tested:

I have tested both wget and curl to bring down file(s) from the internet to to a /tmp/image1.png /tmp/instruction.txt

I then display /tmp/image1.png in a yad dialog. This dialog has a button that can open dialog with /tmp/instruction.txt and closes image. So far, I have not been able to use yad --notepad or --paned dialog wrapper but, will keep trying.

Hope this helps, will update more here after I test more advance yad / bash testing.

[probonopd]

What is it that you want to achieve?

[offternet]

I mainly work with Debian builds to lessen the complexity of terminal tasks for newbie users by creating yad - bash scripted User Interfaces "UIs" . AppImage works as a great containerizer - single - code extracting option for me. The above described beta process si also a lauchpad for my UIs as well. The below detailed explaination is based on a year's worth of using; testing and creating AppImages from appimagehub and other sources. I used the different tools to the exent they worked (some did not work).

Over the past several years many tools have been developed and promoted to allow users to build and manage AppImages. There is no "One App" that does it All for a user to create, manage and launch AppImages. I have tested each one of these many tools over the past year and find them all to be some what difficult to master. So I am trying to work toward a more "newbie friendly" method that can cover all aspects of AppImage creation; launching and Duplication. The more experienced users will not want to use my method. So far, the appimagetool has proven to be rock sold and without any errors, so it is my AppImage tool of choice for creating AppImages.

Another reason for developing a different process is a lot of AppImages on appimagehub work fine under the KDE Distros but fail on Trinity, Xfce, openbox, (and more) Desktop Environments as well as they will not work on most LIVE ISO boots due to missing dependicies. Hopefully, others will step up soon and resolve these failures by updating their AppImages. (I know about hard link dependicies; more about that next paragraph.)

Additionally, concerning some more difficulties is the inability for most AppImage users to persuade a program author (in most cases) to modify "their program(s)" to be compatable with the AppImage (IMHO); just ain't going to happen. There are a few different methods that could be implemented to address the "Hard Linked" dependicies regardless of where the dependices are lcoated. These hard linked dependicies could to be stored within an AppImage; or sourced from the web and temporarily stored under /tmp; or stored on a 2nd partiton of a USB thumb drive linked to the programs hard linked location (as one soulition). I have tested this temporary symlinking to dependices being stored within the AppImage and located in /tmp directory which allowed successful binary propgram execution from within the AppImage without any errors.

And lastly, using yad and bash where script is not compiled will allow awesome flexibility for both users of AppImages and developers who want to intergrate their own options in to a single tool.

[probonopd]

Well...

The AppImage file format is just a self-mounting disk image that executes whatever the author has put inside it.

Authoring AppImage files is considered a task for developers of the respective applications, hence the tools target application developers to create AppImage files as part of their build pipelines.
An application developer can decide how many of the dependencies to bundle - just the ones that cannot reasonably be expected to come with all Linux distributions by default (which is what most application developers currently do) - or everything (in which case the AppImage will run everywhere as long as the kernel is recent enough).

And then there are tools for end users to integrate AppImages into the desktop, etc.

[offternet]

Thank you for the clarification concerning AppImgage Developer and user use scenarios. Is this also the guidelines you use when AppImages are prescreened for possible placement on appimagehub.com ? The reason I ask is, my AppImage Development will allow users to choose from multiple programs provided in a single AppImage.

Would this new technology be allowed on appimagehub.com ?

[probonopd]

A key idea of AppImage is "one app = one file". So every application should have its own AppImage.
That way, the correct icon for the application can be shown on the AppImage, and the correct application can be launched when the AppImage is double-clicked.

I am not affiliated with appimagehub.com, so you'd need to ask them.