Termux integration with custom button feature

[Tcrocks]

Hi all,
Have there been any plans to upgrade the manifest with regard to termux scripting support? From what I understand the termux app requires permissions requests for the com.termux.RUN_COMMAND intent in the requesting app's manifest. This would provide huge benefits and functionality beyond the current plugins.

https://github.com/termux/termux-app/wiki/RUN_COMMAND-Intent

I would be happy to work on this as well as long press contextual upgrades which could integrate into the termux architecture.

Cheers, and thanks for such a great program

[ghisler(Author)]

Sorry, I'm not familiar with Termux. What are you trying to achieve?

[Tcrocks]

Sorry, I'm not familiar with Termux. What are you trying to achieve?

Termux is a linux-like debian-based terminal emulator (sort of) environment that is built on top of android, as an apk with ported packages to work with the Android architecture. It is very well supported and I and many others actively develop on it. It has access to common shared storage areas as well its own separate storage partition and even other app caches if the device is rooted.

With termux, the custom button features in Total Commander could call a script to run within termux (python Ruby shell etc) and all of the logic could be handled within termux and update the shared storage space. This is not limited to file and folder operations, as network tasks can be completed as well. The added functionality would be almost limitless.

If you want to provide streamlined integration you could import these libraries and constants. However, I believe it's only the com.termux.permissions.RUN_COMMAND that is really blocking execution.

Shared libraries:
https://github.com/termux/termux-app/tree/master/termux-shared

Constants for shared library
https://github.com/termux/termux-app/blob/master/termux-shared/src/main/java/com/termux/shared/termux/TermuxConstants.java

You could aslo hand over control to menu-based Termux shell scripts for more fine tuned pre-determined operations or even gui menus in pretty much any language that there is a stable termux package for. The focus could be based on the currently navigated folder or really anything that you pass as a parameter. You wouldn't need to develop plugins to perform network tasks (like upload to a network storage space of your choice); you could handle all of that in Termux and just add a button to manage running your routines.

By integrating with Termux, Total Commander could provide a seamless way for users to perform complex tasks with just a few clicks.

To further illustrate, imagine a user who wants to upload a file to a network storage space. They could click a custom button in Total Commander, which would then trigger a script to run in Termux. The script could use the Termux API to upload the file, and then return control to Total Commander.

The beauty of this approach is that it's highly customizable. Users could write their own scripts in a variety of languages, and tailor the integration to meet their specific needs. They could also use the Termux API to perform a wide range of tasks, from simple file operations to complex network tasks.

To make this integration possible, you could import the Termux shared libraries and constants, which are available on GitHub. This would provide a streamlined way for Total Commander to communicate with Termux and trigger scripts.

I believe that this integration could be a game-changer for Total Commander, and I'd be happy to help make it happen. Let me know if you're interested in discussing this further!

[ghisler(Author)]

As I understand it, the Termux API is used to write extensions for Termux, e.g. when you wanted to call Total Commander functions from Termux, not to start Termux scripts from Total Commander.

Btw, you can already run non-interactive shell scripts from Total Commander, either via sh or su command.

[Tcrocks]

As I understand it, the Termux API is used to write extensions for Termux, e.g. when you wanted to call Total Commander functions from Termux, not to start Termux scripts from Total Commander.

Btw, you can already run non-interactive shell scripts from Total Commander, either via sh or su command.

Thank you for your response. I understand your point about the Termux API being used for writing extensions for Termux, but I'd like to clarify that our goal is to run shell scripts written in Termux from Total Commander.


Regarding the Termux API, you're correct that it's primarily used for interacting with Android-specific features such as the camera, notifications etc. However the API doesn't provide a way to run arbitrary shell scripts or access the Termux file system from an outward-in perspective. I can use the API from within Termux but I would still need permissions to access the API from another app. It's more for interacting with the hardware that is specifc to Android devices.

as for the su and sh commands, while they can be used to run non-interactive shell scripts from Total Commander, they have limitations. The su command is used to run commands with superuser priviledges, but it's not designed to run scripts written in Termux. The sh command can be used to run shell scripts, but it's not aware of the Termux environment either and can't access the Termux file system and run scripts that rely on Termux-specific packages. This would exclude a wide range of Linux packages and tools as well as programming support for programming langauges ranging from C to ruby. As well as many network, audio etc. packages. After the changes to Android 11, termux explicitly requires other apps to be granted permissions to send and execute the intent com.termux.permissions.RUN_SCRIPT. Some other file managers have adopted this approach because they know how useful Termux integration can be. And of course this would always be up to the user of TC if they wanted to grant these permissions or not. Unfortunately for those file managers, they are pretty much garbage when compared to TC and offer little room for customization on their own and dont offer anything comming close to the features you have with the custom buttons. You often need third party tasker applications which are either poorly supported, paid closed source, or very buggy. Even then, you have to deal with whatever inferior file manager happens to work with these tasker applications.

In contrast, using the `com.termux.permissions.RUN_SCRIPT` intent, as we previously discussed would allow us to run Termux scripts directly from TC without requireing modifications to the scripts or the Termux environment and would eliminate the need for these third party tasker applications. This approach would provide a more seamless and integrated experience for users who want to run Termux scripts from Total Commander.

I'd be happy to provide more information oor to clarify any technical detials if you're interested. Thank you again for your response, and I look forward to hearing your thoughts on this matter.

[ghisler(Author)]

So if I understand this correctly, I do not need to include the Termux API. Instead, I need to request the com.termux.permissions.RUN_SCRIPT permission, and then send the RUN_COMMAND intent to execute the script as described here:
https://github.com/termux/termux-app/wiki/RUN_COMMAND-Intent

[JOUBE]

My question here would be, what happens with the output of a script, where is the output visible (maybe Temux comes into forground?)? What's about interactive scripts that may require input (how is this handled in this case at script run from Tc?)?

[Tcrocks]

So if I understand this correctly, I do not need to include the Termux API. Instead, I need to request the com.termux.permissions.RUN_SCRIPT permission, and then send the RUN_COMMAND intent to execute the script as described here:
https://github.com/termux/termux-app/wiki/RUN_COMMAND-Intent

That's exactly right.
I would like to add that importing the termux-shared library, linked in a previous post, would aslo provide some benefit. It would give a TC user access to some useful constants that can be used to interact with Termux. These constants are used to specify the intent actions and extras that are used to communicate with Termux.

Some important constants include:
[*]ACTION_RUN_COMMAND: This is the intent action that is used to run a command in Termux.

[*]EXTRA_COMMAND: This is the extra key that is used to specify the command to be run in Termux.

[*]EXTRA_CURRENT_WORKING_DIRECTORY: This is the extra key that is used to specify the current working directory for the command.

[*]EXTRA_ENVIRONMENT: This is the extra key that is used to specify the environment variables for the command.

[*]EXTRA_FILE_DESCRIPTOR: This is the extra key that is used to specify the file descriptor for the command.

[*]RUN_COMMAND_PERMISSION: This is the permission that is required to run a command in Termux.

Essentially, these constants are used to construct an intent that can be used to run a command in Termux. The intent can be constructed using the Intent class, and the constatns can be used to specify the action, extras and other parameters of the intent.

If you choose to do so, here is the documentation on importing the shared library (which is quite small) to your project:

https://github.com/termux/termux-app/wiki/Termux-Libraries#importing-libraries

[Tcrocks]

My question here would be, what happens with the output of a script, where is the output visible (maybe Temux comes into forground?)? What's about interactive scripts that may require input (how is this handled in this case at script run from Tc?)?

Good questions. you can pipe the output to a file if you need to just like you would be able to in a shell environment. you can also deal with interactive environments through shell, python or even gui menus. You are only limited by the packages currently supported by termux. All interaction would be handed over to Termux and then you could hand it back to TC when an operation is completed. keeping in mind the storage setup of both android devices and the termux storage permissions. With a rooted phone, you can access any location on the phone and the sandboxed storage of the termux app space. with an unrooted phone you are limited to Android 11's app sandboxed spaces. you can't, for instance change the data or settings of another app installed on the phone, but shared storage (where most of your files are located anyways) is freely modifiable by Termux.

https://github.com/termux/termux-packages/wiki/Termux-file-system-layout

So yes, Termux can be set to run in the foreground if you want in interactive session, or your script can run without any visual confirmation at all. If you desired, you could set up logging for retroactively reviewing operations you've executed.

If everything get's implemented I will write a separate post detailing how to set up TC to use Termux in relation to custom buttons as well as share some of my scripts that I think other TC users will find useful and additionaly, some proof of concecpt scripts. Hopefully, others can start to contribute their own scripts as well.

[Tcrocks]

Are there any plans for this in the works?

[ghisler(Author)]

Unfortunately I couldn't get it to work so far. I have installed Termux and tried to follow the instructions, but get a lot of problems:

1. "allow-external-apps property (Mandatory)": I could not find out how to set this. Is there an editor in Temux to access ~/.termux/termux.properties?

2. I tried to run the sample command via ADB:

adb shell am startservice --user 0 -n com.termux/com.termux.app.RunCommandService \
-a com.termux.RUN_COMMAND \
--es com.termux.RUN_COMMAND_PATH '/data/data/com.termux/files/usr/bin/top' \
--esa com.termux.RUN_COMMAND_ARGUMENTS '-n,5' \
--es com.termux.RUN_COMMAND_WORKDIR '/data/data/com.termux/files/home' \
--ez com.termux.RUN_COMMAND_BACKGROUND 'false' \
--es com.termux.RUN_COMMAND_SESSION_ACTION '0'

But it only gives me an error:

Starting service: Intent { cmp=com.termux/.app.RunCommandService }
Error: Not found; no service started.

3. I added <uses-permission android:name="com.termux.permission.RUN_COMMAND" /> to my manifest, but I can't grant the permission via long click on the app icon in task manager - App Info - Permissions.

4. I tried to launch com.termux/com.termux.app.RunCommandService from a button, but it returned an error
"Unable to find explicit activity class com.termux/com.termux.app.RunCommandService.

What am i doing wrong?

[Tcrocks]

I want to thank you for taking the time to work on this. I know it’s a labor of love, but you don’t have to. Let me try to analyze it step-by-step. The first thing you mention is the `allow-external-apps` property. The documentation is very lacking and disjointed (I’m working on it!) there are two ways to set this setting up, you can run `termux-setup-storage` from the termux shell and it will automatically create a virtual storage space and shared space in addition to the `termux.properties` file. This file should be located in a hidden folder at..

`~/.termux/termux.properties`

I believe nano is natively installed with termux. (pkg install nano) you can then `nano ~/.termux/termux.properties` and it believe it is the first commented setting (`allow-external-apps=true`) you’d want to un-comment. The documentation should mention this, but it doesn’t.

After this you would want to run `termux-reload-settings` from the shell. Just an added note: I rarely run termux or edit on it with my thumbs, you can use a program called scrcpy to mess around with it with an actual keyboard.

I think your next issue “Not found; no service started” could easily be related to the allow-external-apps flag not being activated in termux, but not necessarily. If you’re using the latest github or F-droid version of Termux you can extract the Termux’s AndroidManifest.xml file and try running the command with the `--user 0` flag and check it with the following commands:

Code: Select all

adb shell am startservice --user 0 -n com.termux/com.termux.app.RunCommandService \
-a com.termux.RUN_COMMAND \
--es com.termux.RUN_COMMAND_PATH '/data/data/com.termux/files/usr/bin/top' \
--esa com.termux.RUN_COMMAND_ARGUMENTS '-n,5' \
--es com.termux.RUN_COMMAND_WORKDIR '/data/data/com.termux/files/home' \
--ez com.termux.RUN_COMMAND_BACKGROUND 'false' \
--es com.termux.RUN_COMMAND_SESSION_ACTION '0'

There could be an issue with the intent filter. I am going to try and reproduce the issue on my end by modifying your manifest file and see if I get the same issue.

If you want to try and debug at runtime (which is what I’ll be doing) on a development instance you can run:

Code: Select all

adb shell pm grant <your_package_name> com.termux.permission.RUN_COMMAND

and see what you get.

I don’t know what your code actually looks like, but Id imagine you could edit some of it with similar logic:

Code: Select all

import android.content.pm.PackageManager;
import android.os.Bundle;
import android.support.v4.app.ActivityCompat;
import android.support.v7.app.AppCompatActivity;

public class MainActivity extends AppCompatActivity {
    private static final int REQUEST_RUN_COMMAND_PERMISSION = 1;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        //...

        // Request the com.termux.permission.RUN_COMMAND permission
        if (ActivityCompat.checkSelfPermission(this, "com.termux.permission.RUN_COMMAND")!= PackageManager.PERMISSION_GRANTED) {
            ActivityCompat.requestPermissions(this, new String[]{"com.termux.permission.RUN_COMMAND"}, REQUEST_RUN_COMMAND_PERMISSION);
        }
    }

    @Override
    public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
        if (requestCode == REQUEST_RUN_COMMAND_PERMISSION) {
            if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission granted, you can now use the com.termux.permission.RUN_COMMAND permission
            } else {
                // Permission denied, you cannot use the com.termux.permission.RUN_COMMAND permission
            }
        }
    }
}

Do you mind giving some clarification on on your step 3? Does it show the actual permission there, just un-selectable or greyed-out?

I think if it shows up there, there’s no problems with your code. The most likely culprit is what I mentioned in your step one. But maybe not. I would check the system logs to see if there are any error messages related to permission granting.

This can eliminate the possibility that it is a system issue as opposed to a block on the termux side- which I suspect it is.


`adb → dumpsys package`
`adb → pm list permissions`


Lastly, ...RunCommandService isnt classed as an activity (also missing from the docs) its a service, so you’d need to use the `startService()` method. It can be started using an intent but certain extras need to be included in the intent.

I’ll try to give a generalized example.

Code: Select all

Intent intent = new Intent("com.termux.RUN_COMMAND");
intent.setComponent(new ComponentName("com.termux", "com.termux.app.RunCommandService"));
intent.putExtra("com.termux.RUN_COMMAND_PATH", "/data/data/com.termux/files/usr/bin/top");
intent.putExtra("com.termux.RUN_COMMAND_ARGUMENTS", "-n,5");
intent.putExtra("com.termux.RUN_COMMAND_WORKDIR", "/data/data/com.termux/files/home");
intent.putExtra("com.termux.RUN_COMMAND_BACKGROUND", false);
intent.putExtra("com.termux.RUN_COMMAND_SESSION_ACTION", 0);
startService(intent);

Or in TC v 3.30 in the button functionality you can try the settings below: (Im not sure if this is correct but you’d know more about this than I do) For one, I’m not sure if the syntax of `>>` or using ‘service:com.termux/com.termux.app.RunCommandService’ is the proper way. I will test all of this when I patch the manifest and report back with issues. Feel free to PM me as well.

Code: Select all

service:com.termux/com.termux.app.RunCommandService
stream:content://com.termux/files/usr/bin/top
extra:com.termux.RUN_COMMAND_PATH:/data/data/com.termux/files/usr/bin/top
extra:com.termux.RUN_COMMAND_ARGUMENTS:-n,5
extra:com.termux.RUN_COMMAND_WORKDIR:/data/data/com.termux/files/home
extra:com.termux.RUN_COMMAND_BACKGROUND:falseextra:com.termux.RUN_COMMAND_SESSION_ACTION:0

[Tcrocks]

I would add that I always use the github version of the app. There are [many] issues with the play version. You can also embed the modified termux.properties file in the app if you fork termux/termux-packages and edit /packages/termux-tools/build.sh using sed to set the `allow-external-apps=true` in $TERMUX_PKG_SRCDIR/termux.properties and build the bootstrap using the bootstrap you built. Not necessary at all, by the way. I do suspect it to be this setting that is preventing the app from handling the intents.

[ghisler(Author)]

I would add that I always use the github version of the app.

Thanks, that was the important factor to get it to work! The Play Store version did not work AT ALL with 3rd party apps:
1. The settings were in a different directory
2. The line allow-external-apps=false did not exist in it
3. Adding allow-external-apps=true manually did not do anything

I then tried with the Github version and managed to get it to work from Total Commander. However, the adb shell command still returns an error:

Starting service: Intent { act=com.termux.RUN_COMMAND cmp=com.termux/.app.RunCommandService (has extras) }
Error: Requires permission com.termux.permission.RUN_COMMAND

I assume that I need to grant that permission to the app which executes the adb shell commands, but which app is that?

[ghisler(Author)]

I have a strange problem: When I close both Total Commander and Termux via Task Manager, and then try to send a command to Termux via Termux service, I get the following error:

Not allowed to start service Intent { act=com.termux.RUN_COMMAND flg=0x10000000 cmp=com.termux/.app.RunCommandService (has extras) }: app is in background uid null

although checkSelfPermission(termuxPermission) returns PackageManager.PERMISSION_GRANTED.

My guess is that it happens because the Termux service isn't running when Termux itself isn't running. I have to start both Termux and Total Commander manually to be able to send commands from Total Commander to Termux.