Termux:Tasker Documentation

repository·master·Indexed 23 days ago

https://github.com/termux/termux-tasker

A plugin that allows Android automation apps like Tasker to execute commands and scripts within the Termux environment. Includes guides on installation via F-Droid and GitHub, granting necessary permissions (com.termux.permission.RUN_COMMAND and Draw Over Apps), configuring the ~/.termux/tasker/ directory, and managing executable paths, arguments, and stdin. Details the use of output variables such as %stdout, %stderr, and %result, as well as foreground versus background execution and error handling patterns.

Tokens
5.7K
Snippets
5
Records
31
Agent score
32%

What's inside Termux:Tasker

  1. Use Termux path shortcuts in Tasker

    master

    When configuring the Executable or Working Directory fields in the Termux:Tasker plugin, you can use the following shortcuts:

    • $PREFIX/: The Termux prefix directory (/data/data/com.termux/files/usr/).
    • ~/: The Termux home directory (/data/data/com.termux/files/home/).

    If your scripts are located in ~/.termux/tasker/, you can simply provide the filename in the Executable field without a full path.

  2. Understand argument and data size limits

    master

    When using Termux:Tasker, you must adhere to two primary data size limits to avoid exceptions or data loss:

    1. Command/Argument Limit: The total size of the command string and its arguments is limited by the Android ARG_MAX (typically ~128KB). After shell environment overhead, a safe limit is roughly 120KB. Exceeding this results in an Argument list too long error.

      • You can check your specific session limits by running: true | xargs --show-limits.
    2. Intent Data Limit (Result Size): Data exchanged via Android Intents (like %stdout and %stderr) has a practical limit. While Android 7+ might support more, Termux:Tasker sets a safe limit of 100KB and will truncate any data exceeding this.

    Recommendation: Keep arguments under 120KB and results under 100KB. For larger data exchanges, use physical files instead of command output.

  3. Manage plugin output and error variables

    master

    Termux:Tasker populates several local variables after a plugin action.

    Background Commands return:

    • %stdout: Standard output.
    • %stderr: Standard error.
    • %result: The exit code of the command.
    • %err: Set if an error occurred.
    • %errmsg: A descriptive error message.

    Foreground Commands return:

    • %err: Set if an error occurred.
    • %errmsg: A descriptive error message.
    • Note: %stdout, %stderr, and %result are NOT returned for foreground sessions.

    Best Practice: Variable Clearing If you are running multiple plugin actions within a single Task, or using Local Variable Passthrough, you must clear the previous state to avoid false positives. Use the Variable Clear action on %command_failed, %errmsg, %stdout, %stderr, and %result before each new plugin call.

  4. Handle command output and error variables

    master

    When executing plugin actions, the following variables are used to capture results:

    Background Commands

    • %stdout: Standard output from the command.
    • %stderr: Standard error from the command.
    • %result: The exit code of the command.
    • %err: Set if the plugin action itself fails.
    • %errmsg: Error message describing the failure.
    • %command_failed: A boolean-style indicator set if the action failed (detected if %err or %errmsg are set, or if %result is non-zero).

    Foreground Commands

    • Foreground terminal sessions (e.g., running via bash -c) do not return %stdout, %stderr, or %result. They primarily use %err and %errmsg for failure reporting.

    Best Practices for Variable Management

    If you are running multiple plugin actions within a single Task, or using Local Variable Passthrough, you must clear existing result variables before each new action to prevent data from a previous run (especially a failed one) from interfering with the current one. Use the Variable Clear action on:

    • %command_failed (mandatory)
    • %errmsg (optional)
    • %stdout (optional)
    • %stderr (optional)
    • %result (optional)
  5. Run commands in a terminal session vs background

    master

    The Execute in a terminal session toggle changes how the command is executed and how results are returned:

    • Enabled (Foreground): A new terminal session opens automatically.
      • For version >= 0.6.0, results are returned in %stdout and %result.
      • %stdout contains the full session transcript (including stdout, stderr, and PS1 prefixes).
      • For version < 0.6.0, results are not returned to Tasker.
    • Disabled (Background): Commands run in the background. Results are returned in %stdout, %stderr, and %result.
  6. Configure command arguments

    master

    The Arguments field defines arguments passed to the executable. For version >= 0.5, arguments are parsed using shell-like rules (via ArgumentTokenizer).

    • Delimiters: Arguments are split by whitespace ( , \t, \n) unless enclosed in single (') or double (") quotes.
    • Escaping: Double quotes and backslashes can be escaped with a backslash \ inside double quotes.
    • Literal Strings: Single quotes ' create literal strings. To include a single quote inside a single-quoted argument, you must escape it by replacing ' with '\''.

    Tasker Tip: To escape single quotes in Tasker, use the Variable Search Replace action on your %argument variable:

    • Search: '
    • Replace Matches: Enabled
    • Replace With: '\'' (Note: In Tasker's UI, you may need to use \'' to ensure the backslash is handled correctly).
  7. Manage executable permissions for Termux:Tasker

    master

    Termux:Tasker handles permissions differently based on the file location:

    • Inside ~/.termux/tasker/: Execute permissions are automatically set when the plugin action runs.
    • Outside ~/.termux/tasker/: You must manually set read and execute permissions. Use the following command in a Termux terminal session before running the plugin action:
    chmod 700 "/path/to/executable"
  8. Configure the `~/.termux/tasker/` directory for scripts

    master

    You can store scripts in ~/.termux/tasker/ to run them via the plugin without needing to use absolute paths or enabling allow-external-apps.

    To set this up, run the following commands in a non-root Termux session to create the directory with the required 0700 permissions:

    mkdir -p /data/data/com.termux/files/home/.termux/tasker
    chmod 700 -R /data/data/com.termux/files/home/.termux

    Note: The tasker directory must have read permission for the plugin to find scripts, and the scripts themselves must have executable permissions.

  9. Setup template test scripts in Termux

    master

    The Basic Templates require specific test scripts to be present in ~/.termux/tasker/.

    1. Download Scripts

    Run these commands in a non-root Termux shell to download the Bash and Python test scripts directly to the required directory:

    curl -L 'https://github.com/termux/termux-tasker/raw/master/templates/scripts/termux_tasker_basic_bash_test' -o "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_bash_test"
    
    curl -L 'https://github.com/termux/termux-tasker/raw/master/templates/scripts/termux_tasker_basic_python_test' -o "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_python_test"

    Alternatively, download them to your Download folder and move them using cat or a SAF-compatible file browser.

    2. Set Permissions

    Ensure the scripts are executable:

    chmod 700 "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_bash_test"
    chmod 700 "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_python_test"
    curl -L 'https://github.com/termux/termux-tasker/raw/master/templates/scripts/termux_tasker_basic_bash_test' -o "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_bash_test"
    
    curl -L 'https://github.com/termux/termux-tasker/raw/master/templates/scripts/termux_tasker_basic_python_test' -o "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_python_test"
    
    chmod 700 "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_bash_test"
    chmod 700 "/data/data/com.termux/files/home/.termux/tasker/termux_tasker_basic_python_test"
  10. Prerequisites for using Termux:Tasker plugin

    master

    To successfully run commands via the Termux:Tasker plugin, ensure the following requirements are met:

    1. Plugin Version: Termux:Tasker version >= 0.5 is required.
    2. Permissions:
      • Tasker must be granted com.termux.permission.RUN_COMMAND permission.
      • For Android >= 10, Termux must be granted Draw Over Apps permission. This allows foreground commands to execute automatically without requiring the user to manually tap a notification in the status bar.
    3. Script Locations: Scripts intended for use via the plugin should be placed in ~/.termux/tasker/ (e.g., ~/.termux/tasker/termux_tasker_basic_bash_test).
    4. External App Access: If running commands using absolute paths outside the ~/.termux/tasker/ directory (such as $PREFIX/bin/bash), you must set allow-external-apps = true in your ~/.termux/termux.properties file.
  11. Handle command results and errors in Tasker

    master

    When running plugin actions, the availability of output variables depends on your timeout and toggle settings:

    Variable Availability

    • If timeout > 0 AND Wait for result for commands is ENABLED:
      • %stdout: Standard output.
      • %stderr: Standard error (only for background commands).
      • %result: The command result.
      • %err and %errmsg: Set if the action fails (e.g., executable not found, permission issues, or timeout).
    • If timeout > 0 AND Wait for result for commands is DISABLED:
      • %stdout, %stderr, and %result will not be returned.
      • Only %err and %errmsg may be set on failure.

    Important Timeout Notes

    • Default Timeout: 10s. If running long background commands, increase this or set to Never (slider to the extreme right).
    • Avoid timeout 0: Do not use 0 even for foreground sessions. Using 0 prevents the plugin from returning error information in %err and %errmsg, meaning you won't know if a command failed.
    • Variable Clearing: For version >= 0.5, %errmsg, %stdout, %stderr, and %result are automatically cleared before each run if timeout > 0. For older versions, manually clear them using a Tasker Variable Clear action with pattern matching: %errmsg/%stdout/%stderr/%result.

    Data Limits

    • Truncation: If output is too large, Termux truncates %stdout and %stderr to a combined max of 100KB (from the start). %errmsg is truncated from the end to a max of 25KB.
  12. Implement error checking for plugin actions

    master

    Because Tasker sets and clears %err for each action, the variable is only available in the next action. To reliably check for errors, follow this pattern:

    1. Clear previous state: Add a Variable Clear action for a custom variable (e.g., %command_failed) before the plugin action.
    2. Run Plugin Action.
    3. Capture error state: Immediately after the plugin action, add a Variable Set action:
      • Name: %command_failed
      • To: %err %errmsg
      • Conditions: If %err Set OR If %errmsg Set.
    4. Evaluate: Use If %command_failed Set to trigger error handling (e.g., Flash a message or exit the task).

    It is also recommended to check %result and %stderr for logical command failures.