termux-packages

termuxでミラーサイトを更新する方法 termuxでミラーサイトを更新する 問題意識 termuxでパッケージを更新する際、毎回世界中のミラーサイトを巡回してからダウンロードを始めていたのでダウロードが遅かった。 解決方法 ミラーサイトを更新すれば良い。以下の手順でできた。 以下のtermux-tools パッケージの一部のtermux-change-repoスクリプトを実行する。 termux-change-repo 以下の画面が表示されるので Signle mirrorを選択 次の画面が表示されるので お近くのmirrorsを選択。日本の場合はMirrors in Asiaを選択。 参照 公式ドキュメント あとがき 良ければハートやフォロー、X:@w4daka_tterのフォロー、Github:@w4dakaのフォローお願いします。

GNOME Desktop is now available in termux! preview.redd.it termux-packages#32883 Tras muchos intentos, tazas de café y pruebas, y gracias al esfuerzo monumental de la comunidad para integrar GNOME Shell en Termux, ¡lo hemos conseguido! Es 100% funcional; funciona incluso sin aceleración gráfica por hardware, ¡e incluso se ejecuta dentro de una sesión VNC! Puedes descargar los archivos de la solicitud de extracción y probarlos tú mismo. Por fin tenemos otro entorno de escritorio completamente funcional en Termux: una excelente alternativa para quienes no somos especialmente aficionados a KDE.

GNOME 49 desktop native on termux with gnome-sesion-sheperd I have managed to build GNOME 49 in Termux and adapt `gnome-shell-shepherd` to launch GNOME services—without requiring `systemd`—using `gherd/shepherd`. I would appreciate it if you could test it and provide feedback on how it works.

How to Distribute Your Own Tools on Termux: A Guide for Developers --- title: "How to Distribute Your Own Tools on Termux: A Guide for Developers" published: true description: "Built a CLI tool that runs on Termux but can't get into termux-packages or TUR? Here are all your options for distributing it to Termux users: official repo, TUR, your own APT repo, and Termux App Store." tags: termux, android, opensource, tutorial cover_image: your-image-url (1000x420 recommended) canonical_url: your-site.com --- You built a CLI tool. It runs great on Termux. Now you want other Termux users to install it with one command instead of git clone, dependency hunting, and "it doesn't compile on my phone." Then you open a pull request to the official repository, and it gets closed. Or you try TUR and the review stalls. You're not alone, and it doesn't mean your tool is bad. It usually means the tool doesn't fit that channel. This guide walks through every realistic way to distribute your own tools on Termux, what each one expects from you, and how to pick the right one. > Disclosure: I maintain Termux App Store, one of the options below. It is an independent community project and is not affiliated with the official Termux project. I'll be upfront about trade-offs for every option, including mine. TL;DR | Option | Best for | Review process | Users install with | |---|---|---|---| | termux-packages (official) | Widely used, stable, general-purpose software | Strict, maintained by the core team | pkg install | | TUR (Termux User Repository) | Packages that don't fit official but still need a curated home | Curated contributor workflow | pkg install (after enabling the repo) | | Your own APT repository | Full control, your own release cadence | None (you are the reviewer) | pkg install (after users add your repo) | | Termux App Store | Niche, experimental, or fast-moving community tools | Pull request with validation tooling | termux-app-store install | | GitHub release + install script | Quick start, small audience | None | curl ... \| bash or manual | If you only read one line: start by asking who your users are and how much control you want over releases, then choose. Why your package may get rejected Official and curated repositories exist to protect users and reduce maintenance load. A few common reasons a new tool doesn't fit: - Scope. The official repo targets software with broad use. A small or niche tool may not meet that bar. - Maintenance burden. Every package needs someone to keep it building across architectures when Termux's toolchain changes. - Build reproducibility. Packages must build from source inside the Termux build environment, not just run on your phone. - Upstream fit. Projects with bundled binaries, unusual licensing, or heavy patching are harder to accept. None of this is a judgement on your code. It's a question of which channel matches your project. Option 1: The official termux-packages repository The build system and primary set of packages for Termux live in termux/termux-packages. Packages are organized into repository channels such as main, root, and x11, and each package is a directory with a build.sh. Choose this if your tool is stable, widely useful, and you're willing to maintain it long term. Do this first: read CONTRIBUTING.md and the Developer's Wiki in that repo. Check whether a similar package already exists, and make sure your project has a clear license and tagged releases. Option 2: TUR (Termux User Repository) TUR is described as the Termux equivalent of the Arch User Repository idea: users install pre-compiled packages instead of building on-device. Packages live under tur/<your-package-name>/build.sh (not packages/), and you build with the Termux build scripts: TERMUX_INSTALL_DEPS=true ./build-package.sh -a <arch> <package-name> Two things to remember: - TUR packages are not official Termux packages. Don't ask the core Termux team for support on them. - TUR has a curated contributor workflow, so expect review. Option 3: Host your own APT repository If you want full control, you can build .deb packages and host them as an APT repository (for example on GitHub Pages). Users add your repository, then install with pkg or apt. Pros: your release schedule, your rules. Cons: you handle signing, hosting, architecture builds (aarch64, arm, x86_64, i686), and user trust. Every user has to add your repo first. This is the most work, but it's the right call for larger projects with their own ecosystem. Option 4: Termux App Store (community package layer) Termux App Store is a community-driven TUI and CLI package manager for Termux. Think of it as an AUR-like layer for tools that are too niche, too experimental, or too fast-moving for the official repository. Packages are described by a build.sh file. Users can install a pre-built .deb (fast path, SHA256-verified) or force a source build. Step 1: Get the tooling git clone https://github.com/djunekz/termux-app-store cd termux-app-store Step 2: Create your build.sh Every package is just one file: packages/<tool-name>/build.sh. It tells Termux App Store what your tool is, where to download it, and how to install it. You don't have to write it by hand. Pick whichever of these three ways fits you: | Way | Best for | Command | |---|---|---| | A. pkg-scaffold.py (wizard) | Beginners. It asks questions and writes the file for you | python pkg-scaffold.py | | B. termux-build | People who want a template or a one-line generator | ./termux-build init <github-url> | | C. Manual | People who already know the format | Copy template/build.sh and edit | Way A: the scaffold wizard (easiest) Run it from inside the cloned repo: python pkg-scaffold.py Or give it your GitHub URL up front so it can pre-fill everything: python pkg-scaffold.py --from https://github.com/yourname/my-awesome-cli The wizard walks you through a few steps: 1. Source repository (optional). Paste your GitHub URL and it fetches the description, license, and latest release or tag automatically. 2. Package info: name (lowercase and hyphens only), description, homepage, license, maintainer, version. 3. SHA256. It can download your source and compute the checksum for you. 4. Build method. It scans your repo and detects whether it's a Python script, pip package, shell script, npm, Cargo (Rust), Go, Makefile, CMake, and more. 5. Entrypoint (for script-type tools) and any extra dependencies. 6. Review, then confirm, and it writes packages/my-awesome-cli/build.sh. If you don't give it a GitHub URL, it just asks you to type everything in manually. Way B: termux-build Generate a blank template: ./termux-build create my-awesome-cli Or auto-create from a GitHub repository: ./termux-build init https://github.com/yourname/my-awesome-cli Both give you packages/my-awesome-cli/build.sh. Note that termux-build is mainly a creation and validation helper. It is not an auto-publish tool, so nothing gets uploaded until you open a pull request yourself. Step 3: Check the metadata (and fix anything the tools missed) Whichever way you used, open the generated file and make sure it looks right. A package definition carries metadata like this: TERMUX_PKG_HOMEPAGE="https://github.com/yourname/my-awesome-cli" TERMUX_PKG_DESCRIPTION="One-line description of what the tool does" TERMUX_PKG_LICENSE="MIT" TERMUX_PKG_MAINTAINER="@yourname" TERMUX_PKG_VERSION="1.0.0" TERMUX_PKG_SRCURL="https://github.com/yourname/my-awesome-cli/archive/refs/tags/v${TERMUX_PKG_VERSION}.tar.gz" TERMUX_PKG_SHA256="<sha256 of the source tarball>" Get the checksum with: curl -L <your-source-url> | sha256sum > The exact required fields can evolve, so run ./termux-build guide and ./termux-build template for the current format. Step 4: Validate before you submit ./termux-build lint my-awesome-cli # check the package ./termux-build check-pr my-awesome-cli # check it's ready for a pull request ./termux-build doctor # diagnose your environment Step 5: Open a pull request Push your branch and open a PR with your packages/my-awesome-cli/ directory. After it's merged, users can find and install it: pip install termux-app-store termux-app-store search my-awesome-cli termux-app-store install my-awesome-cli Prefer to compile locally? Users can force a source build with termux-app-store fix-install my-awesome-cli. The whole flow in 4 commands git clone https://github.com/djunekz/termux-app-store && cd termux-app-store python pkg-scaffold.py --from https://github.com/yourname/my-awesome-cli # 1. generate build.sh ./termux-build lint my-awesome-cli # 2. validate it ./termux-build check-pr my-awesome-cli # 3. check PR readiness # 4. commit packages/my-awesome-cli/ and open a Pull Request Trade-off to be aware of: because this is an independent community layer, it is not the official Termux repository and packages aren't installed through plain pkg install. In exchange you get a much lower barrier to entry. Option 5: GitHub releases plus an install script The fastest way to ship: publish release binaries or a script on GitHub and document a one-liner. pkg install git git clone https://github.com/yourname/my-awesome-cli cd my-awesome-cli && ./install.sh It works, but there is no update mechanism, no checksum verification by default, and users have to trust and read your script. Fine for early versions; plan to graduate to one of the options above. Checklist before you distribute anywhere - [x] A clear license file - [x] Tagged releases with a stable source URL - [x] A SHA256 checksum for every release artifact - [x] Tested on at least aarch64, ideally also arm and x86_64 - [x] Declared dependencies (pkg install ...) - [x] No hardcoded /usr/bin. Termux uses $PREFIX (/data/data/com.termux/files/usr) - [x] A README with a copy-pasteable install command - [x] No telemetry or surprising network calls without disclosure FAQ Why was my package rejected from termux-packages? Usually scope, maintenance burden, or build reproducibility. Read the contributing guide, check for existing packages, and consider TUR or a community layer instead. What's the difference between termux-packages and TUR? termux-packages is the official, core-maintained repository. TUR is a separate user repository with its own curated workflow, and its packages are not official Termux packages. Can I distribute a Termux package without asking anyone's permission? Yes. Host your own APT repository or release .deb files yourself. You trade review for responsibility. How do I make a .deb for Termux? Use the Termux build system (build-package.sh with a build.sh) so paths and prefixes are correct for Termux rather than a standard Linux distro. Which architectures should I support? Termux runs on aarch64, arm, x86_64, and i686. aarch64 covers most modern phones. Wrapping up There's no single "right" place to publish a Termux tool. Use the official repo for stable, broadly useful software, TUR for curated extras, your own APT repo when you want total control, and a community layer like Termux App Store when your tool is niche or moving fast. Whichever you choose, ship checksums, document the install command, and test on more than one architecture. Your users will thank you. If you've got a Termux tool you want more people to use, packaging it is the highest-leverage thing you can do. Questions or war stories about getting packages rejected? Drop them in the comments. --- Links - Termux App Store: djunekz/termux-app-store - Termux packages (official): termux/termux-packages - TUR: termux-user-repository/tur

Sentinel-IR on Android: Install It in Termux Mobile and Verify the Output, Step by Step !Image description From a fresh Termux terminal to a real, inspectable JavaScript analysis report. No desktop computer, no API key, no AI account required. > What this guide does: installs the published sentinel-ir@0.1.1 package, initializes its bundled WebAssembly parser, analyzes a tiny JavaScript example, checks expected results, and saves a JSON report. It then shows how to analyze one JavaScript file you own and how to share sanitized findings under your own account. > > What it does not do: it does not prove that a program is secure, scan an entire repository, analyze TypeScript/JSX reliably, or send source code to an LLM. The 0.1.1 release was tested in Termux. This walkthrough uses the published package's documented API and includes troubleshooting because Android and Termux installations can differ. Thanks for support.. Release: "Sentinel-IR-MCP v0.2.2 on GitLab" (gitlab.com) Package: "sentinel-ir-mcp@0.2.2 on npm" (npmjs.com) ⚡ The 20-Second Version You can run a small JavaScript structural analyzer from an Android phone. Termux gives Android a Linux-style terminal, Node.js runs JavaScript, and Sentinel-IR turns a source string into a compact JSON report with facts such as recognized routes, imports, environment variables, operations, and risk signals. The point of this tutorial is simple: do not take my word for it. Install the exact published version, run the sample, and inspect the output yourself. If you find a problem, report it from your account, with enough detail for someone else to reproduce it. Yes, this is the kind of project you can experiment with from bed instead of spending the entire evening scrolling. Your phone is not a magic workstation, and not every idea becomes a product. But it can be enough to run a real, testable experiment. 🗺️ Quick Navigation Tap any link below to jump directly to that section. At the end of each phase, use Contents to return here or Next to continue without scrolling back to the top. - [The 20-Second Version](#the-20-second-version) - [How to read the visual markers](#how-to-read-the-visual-markers) - [Before We Start: What You Need](#before-we-start-what-you-need) - [Phase 0: Open Termux](#phase-0-open-termux-and-understand-the-terminal) - [Phase 1: Update Termux](#phase-1-update-termux-packages) - [Phase 2: Install Node.js](#phase-2-install-nodejs-and-npm) - [Phase 3: Create a test folder](#phase-3-create-a-clean-test-folder) - [Phase 4: Install Sentinel-IR](#phase-4-install-the-exact-published-release) - [Phase 5: Check the API](#phase-5-check-that-the-public-api-exists) - [Phase 6: Initialize WebAssembly](#phase-6-initialize-the-bundled-webassembly-parser) - [Phase 7: Create the sample](#phase-7-create-a-harmless-javascript-sample) - [Phase 8: Create the analysis script](#phase-8-create-a-small-analysis-program) - [Phase 9: Run the analysis](#phase-9-run-the-analysis-and-save-a-report) - [Phase 10: Verify the findings](#phase-10-verify-the-findings-instead-of-just-looking-at-a-json-blob) - [Phase 11: Try your own file (optional)](#phase-11-try-a-javascript-file-of-your-own-optional) - [Option A: File inside Termux](#option-a-the-file-is-already-inside-termux) - [Option B: File in Android Downloads](#option-b-the-file-is-in-android-downloads) - [Phase 12: Understand the result](#phase-12-understand-analysisstatus) - [Phase 13: Share findings safely](#phase-13-share-a-result-without-leaking-your-code) - [Troubleshooting](#troubleshooting-if-something-goes-wrong) - [Repository errors](#repository-errors-when-running-pkg-update) - [node: command not found](#node-command-not-found) - [Node.js is older than version 20](#nodejs-is-older-than-version-20) - [Native build warnings or errors](#npm-install-shows-native-build-warnings-or-errors) - [Cannot find module 'sentinel-ir'](#cannot-find-module-sentinel-ir) - [WebAssembly initialization failed](#webassembly-initialization-failed) - [analysisStatus is incomplete](#analysisstatus-is-incomplete) - [Expected route or import is missing](#the-expected-route-or-import-is-missing) - [npm cannot reach the registry](#npm-cannot-reach-the-registry) - [What Counts as a Successful Finish?](#what-counts-as-a-successful-finish) - [One Final Invitation](#one-final-invitation) How to read the visual markers - 🟦 DO THIS: copy the command block into Termux and press Enter. - ✅ EXPECTED RESULT: compare your terminal output with this example. - ⚠️ IF THIS FAILS: stop at that step and use the linked troubleshooting section. - 🧪 OPTIONAL: skip it on your first run if you only want to verify the package. Do one step at a time. Continue only when the expected result makes sense. The coloured code syntax and headings are part of DEV.to's normal rendering, not evidence that a test passed. 📦 Before We Start: What You Need - An Android phone supported by Termux. - A working internet connection for the initial package downloads. - A little free storage. Node.js and npm dependencies need room, so do not start with your storage completely full. - Around 10 to 20 minutes if package downloads behave. Slow mirrors or older installations can take longer. - No root access, no API key, no OpenAI account, and no desktop computer. Use the official Termux sources. The maintainers document installation through F-Droid and the official GitHub repository. Avoid random APK files from chat groups or download sites. If you already have Termux installed, do not uninstall it casually: builds from different sources may use different signing keys. Update the installation you already have unless you have a specific reason to switch. Official project references: - Sentinel-IR npm package, version 0.1.1 - Sentinel-IR README for tag v0.1.1 - Sentinel-IR source tag v0.1.1 - Official Termux installation instructions --- 🧭 Phase 0: Open Termux and understand the terminal Open Termux. You should see a terminal prompt and a blinking cursor. Type or paste a command, then press Enter. Commands in this guide should be run inside Termux unless a step explicitly says otherwise. A few phone-specific tips: - Paste one code block at a time. Wait for the prompt to return before pasting the next block. - If you see a long stream of installation text, that is normal. Read the last few lines if a command fails. - Do not paste a line that begins with a prompt character such as $. The $ in documentation usually means “type the command after this symbol”. The blocks below omit it. - If Android closes Termux in the background, reopen it and run the last command again. Do not assume a command completed just because you switched apps. - You do not need to grant access to all shared phone storage for the first test. We will create everything inside Termux's private home directory. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 1](#phase-1-update-termux-packages) 🧭 Phase 1: Update Termux packages Run: 🟦 DO THIS · Run in Termux pkg update && pkg upgrade -y pkg update refreshes the package lists. pkg upgrade -y updates installed packages and automatically accepts the package manager's normal confirmation prompt. > ✅ IF IT WORKS: if the command finishes and returns to the prompt, continue. > > ⚠️ IF THIS FAILS: if it stops with a repository or mirror error, jump to [Troubleshooting: repository errors](#repository-errors-when-running-pkg-update) below. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 2](#phase-2-install-nodejs-and-npm) 🧭 Phase 2: Install Node.js and npm Sentinel-IR requires Node.js 20 or newer. npm normally comes with the Termux Node.js package. 🟦 DO THIS · Run in Termux pkg install nodejs -y Now check both tools: 🟦 DO THIS · Run in Termux node --version npm --version Node should print a version number such as v20.x, v22.x, v24.x, or newer. The exact current version depends on the Termux repository and the day you install it. npm should also print a version number. Use this extra check to verify the Node major version numerically: 🟦 DO THIS · Run in Termux node -e "const major = Number(process.versions.node.split('.')[0]); console.log('Node.js:', process.version); if (major < 20) { console.error('Sentinel-IR requires Node.js 20 or newer'); process.exit(1); } console.log('PASS: Node.js version is supported');" ✅ EXPECTED RESULT PASS: Node.js version is supported > ⚠️ IF THIS FAILS: if Node is below 20, do not continue and hope for the best. Update Termux packages and check the available Node package again. See [Troubleshooting: old Node.js](#nodejs-is-older-than-version-20). ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 3](#phase-3-create-a-clean-test-folder) 🧭 Phase 3: Create a clean test folder Keep the experiment separate from your photos, downloads, and other projects. 🟦 DO THIS · Run in Termux mkdir -p "$HOME/sentinel-ir-termux-test" cd "$HOME/sentinel-ir-termux-test" pwd The final command should print a path inside Termux's home directory, usually beginning with /data/data/com.termux/files/home/. Every file created in the remaining steps will live in this folder. You can return to it later with: 🟦 DO THIS · Run in Termux cd "$HOME/sentinel-ir-termux-test" ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 4](#phase-4-install-the-exact-published-release) 🧭 Phase 4: Install the exact published release First, create a minimal local npm project: 🟦 DO THIS · Run in Termux npm init -y Install the exact release covered by this guide, rather than whichever version might be published as latest in the future: 🟦 DO THIS · Run in Termux npm install --save-exact sentinel-ir@0.1.1 This package has a regular web-tree-sitter dependency and optional native Tree-sitter dependencies. The normal install may try to install those optional native packages too. Our test will explicitly use the bundled WebAssembly parser through analyzeAsync(), which is the intended path when native parser packages are unavailable. Check that npm installed the exact version: 🟦 DO THIS · Run in Termux npm ls sentinel-ir You should see sentinel-ir@0.1.1 in the dependency tree. The package is installed locally in this test folder. You do not need a global npm installation and should not use sudo in Termux. You can independently ask the public registry which version it serves: 🟦 DO THIS · Run in Termux npm view sentinel-ir@0.1.1 version ✅ EXPECTED RESULT 0.1.1 > ⚠️ IF THIS FAILS: if this command says it cannot reach the registry, that is a network or registry access issue, not evidence that the analyzer failed. Check your connection and use the troubleshooting section. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 5](#phase-5-check-that-the-public-api-exists) 🧭 Phase 5: Check that the public API exists Run this block exactly as shown: 🟦 DO THIS · Run in Termux node - <<'NODE' const sentinel = require('sentinel-ir'); for (const name of ['analyzeAsync', 'compress', 'initializeWasm']) { console.log(`${name}: ${typeof sentinel[name]}`); if (typeof sentinel[name] !== 'function') { console.error(`FAIL: missing function ${name}`); process.exitCode = 1; } } if (!process.exitCode) { console.log('PASS: expected Sentinel-IR functions are exported'); } NODE The three lines should end in function, followed by: ✅ EXPECTED RESULT PASS: expected Sentinel-IR functions are exported > ⚠️ IF THIS FAILS: if you see Cannot find module, check that your terminal is still in the test directory and run npm ls sentinel-ir again. If the installed version is not 0.1.1, return to Phase 4. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 6](#phase-6-initialize-the-bundled-webassembly-parser) 🧭 Phase 6: Initialize the bundled WebAssembly parser This is a direct check of the WebAssembly initialization path, before we analyze a file. 🟦 DO THIS · Run in Termux node - <<'NODE' const { initializeWasm } = require('sentinel-ir'); initializeWasm() .then(() => { console.log('PASS: Sentinel-IR WebAssembly parser initialized'); }) .catch((error) => { console.error('FAIL: WebAssembly initialization failed'); console.error(error); process.exitCode = 1; }); NODE ✅ EXPECTED RESULT PASS: Sentinel-IR WebAssembly parser initialized > ⚠️ IF THIS FAILS: if initialization fails, do not quietly move to the next step. See [Troubleshooting: WebAssembly initialization](#webassembly-initialization-failed). The usual checks are whether the package finished installing, whether the packaged WASM file exists, and whether the exact version is installed. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 7](#phase-7-create-a-harmless-javascript-sample) 🧭 Phase 7: Create a harmless JavaScript sample We will analyze text that looks like a tiny Express-style server. Sentinel-IR analyzes the source text; this guide does not run the server. You do not need to install Express because the code is only the input to the parser. Create the sample: 🟦 DO THIS · Run in Termux cat > sample.js <<'JS' const express = require("express"); const fs = require("fs"); const app = express(); app.post("/upload", (req, res) => { fs.writeFileSync("/tmp/upload", req.body); res.end(); }); app.listen(process.env.PORT); JS Check the file was created: 🟦 DO THIS · Run in Termux cat sample.js You should see the JavaScript block you just pasted. You can also check its syntax with Node.js without executing the server: 🟦 DO THIS · Run in Termux node --check sample.js If the syntax check succeeds, Node normally prints nothing and returns to the prompt. If it reports a syntax error, recreate the file using the full cat block above. Be careful not to include the Markdown code fences in the file. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 8](#phase-8-create-a-small-analysis-program) 🧭 Phase 8: Create a small analysis program Now create a reusable script. It reads one JavaScript file, passes the text to analyzeAsync(), compresses the result, and prints JSON. It does not execute the input file, call an LLM, or upload the input. 🟦 DO THIS · Run in Termux cat > analyze.js <<'JS' const fs = require('node:fs/promises'); const path = require('node:path'); const { analyzeAsync, compress } = require('sentinel-ir'); async function main() { const inputPath = process.argv[2]; if (!inputPath) { console.error('Usage: node analyze.js <file.js>'); process.exitCode = 1; return; } const source = await fs.readFile(inputPath, 'utf8'); const ir = await analyzeAsync(source, { // Use only the filename in the report, not the full private device path. target: path.basename(inputPath), }); const report = compress(ir); console.log(JSON.stringify(report, null, 2)); if (report.analysisStatus !== 'complete') { console.error( 'WARNING: analysisStatus is not complete. Do not treat this result as a complete structural analysis.' ); process.exitCode = 2; } } main().catch((error) => { console.error('ERROR: analysis could not finish.'); console.error(error && error.stack ? error.stack : error); process.exitCode = 1; }); JS Check the wrapper's own syntax: 🟦 DO THIS · Run in Termux node --check analyze.js Again, a successful syntax check normally prints nothing. This tests the small wrapper, not Sentinel-IR's accuracy. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 9](#phase-9-run-the-analysis-and-save-a-report) 🧭 Phase 9: Run the analysis and save a report Run: 🟦 DO THIS · Run in Termux node analyze.js sample.js > report.json rc=$? printf 'Analyzer exit code: %s\n' "$rc" The JSON is saved in report.json, not lost in a wall of terminal output. The exit code means: - 0: the script produced a result whose analysisStatus is complete. - 2: a result was produced, but the analysis status was not complete. Read the warning and do not count this as a successful complete analysis. - 1: the wrapper could not finish, for example because it could not read the input or initialize the parser. Display the report: 🟦 DO THIS · Run in Termux cat report.json The report is JSON. Its exact formatting and some values can vary with the input, but for the supplied valid JavaScript sample you should expect structural facts resembling these: - analysisStatus should be complete. - facts.ast should be true. - facts.routes should include POST /upload. - facts.imports should include express and fs. - facts.env should include PORT. - The report should include recognized operations and risk signals related to the route and file write. The report's risk estimate is not a verdict that this example is safe or unsafe. The sample deliberately includes an HTTP route and a filesystem write so there is something tangible to inspect. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 10](#phase-10-verify-the-findings-instead-of-just-looking-at-a-json-blob) 🧭 Phase 10: Verify the findings instead of just looking at a JSON blob Run an automatic check against the results we expect from the sample: 🟦 DO THIS · Run in Termux node - <<'NODE' const report = require('./report.json'); const failures = []; if (report.analysisStatus !== 'complete') { failures.push(`analysisStatus expected complete, got ${report.analysisStatus}`); } if (report.facts?.ast !== true) { failures.push('facts.ast expected true'); } if (!Array.isArray(report.facts?.routes) || !report.facts.routes.includes('POST /upload')) { failures.push('expected route POST /upload was not found'); } if (!Array.isArray(report.facts?.imports) || !report.facts.imports.includes('express')) { failures.push('expected import express was not found'); } if (!Array.isArray(report.facts?.imports) || !report.facts.imports.includes('fs')) { failures.push('expected import fs was not found'); } if (!Array.isArray(report.facts?.env) || !report.facts.env.includes('PORT')) { failures.push('expected environment variable PORT was not found'); } if (failures.length) { console.error('FAIL: sample analysis did not match expectations'); for (const failure of failures) console.error(`- ${failure}`); process.exitCode = 1; } else { console.log('PASS: the sample produced the expected structural facts'); } NODE ✅ EXPECTED RESULT PASS: the sample produced the expected structural facts This is a reproducible smoke test. It shows that this installed package can parse this particular sample and return the facts checked by the script. It is not a broad benchmark, a full test suite, or proof that every JavaScript pattern is recognized correctly. You can also print the most useful fields without dumping the whole report: 🟦 DO THIS · Run in Termux node - <<'NODE' const r = require('./report.json'); console.log('analysisStatus:', r.analysisStatus); console.log('routes:', r.facts.routes); console.log('imports:', r.facts.imports); console.log('environment variables:', r.facts.env); console.log('operations:', r.facts.operations); console.log('risk signals:', r.facts.riskSignals); NODE ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 11](#phase-11-try-a-javascript-file-of-your-own-optional) 🧭 Phase 11: Try a JavaScript File of Your Own · 🧪 OPTIONAL You have already tested the package with a known sample. Only now try your own input. Only analyze code you own or are authorized to inspect. Start with one .js file, not an entire repository. Sentinel-IR analyzes one JavaScript file at a time; it does not combine calls or data flow across files. 📁 Option A: The file is already inside Termux Copy your file into the test directory, or run the analyzer with its path: 🟦 DO THIS · Run in Termux node analyze.js ./your-file.js > your-file-report.json rc=$? printf 'Analyzer exit code: %s\n' "$rc" Replace your-file.js with the real filename. If you need to keep a report, give it a different name so you do not overwrite report.json. 📱 Option B: The file is in Android Downloads For this optional path, grant Termux shared-storage access only if you need it: 🟦 DO THIS · Run in Termux termux-setup-storage Android may show a permission dialog. Approve it if you want Termux to read your shared files. Then list Downloads: 🟦 DO THIS · Run in Termux ls "$HOME/storage/downloads" Copy one JavaScript file into the private test folder, replacing example.js with its exact filename: 🟦 DO THIS · Run in Termux cp "$HOME/storage/downloads/example.js" "$HOME/sentinel-ir-termux-test/your-file.js" cd "$HOME/sentinel-ir-termux-test" node analyze.js your-file.js > your-file-report.json rc=$? printf 'Analyzer exit code: %s\n' "$rc" 💡 TIP: if the filename contains spaces, keep the quotation marks. If the file is not listed in Downloads, check the correct folder name with ls. You do not need to enable this permission for the earlier sample test. A file can be JavaScript-shaped but still use syntax that Sentinel-IR does not support. The package currently targets JavaScript, including CommonJS and ESM. It does not claim general TypeScript, JSX-heavy, or other-language support. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 12](#phase-12-understand-analysisstatus) 🧭 Phase 12: Understand analysisStatus This field is one of the most important parts of the output. - complete means AST extraction succeeded and the source parsed without syntax errors. It does not mean every security issue was found. - incomplete means AST extraction was unavailable or the source did not parse cleanly. The output may rely on text-based fallback heuristics, which can be wrong in either direction. > ⚠️ IF THIS FAILS: if a report is incomplete, do not write “Sentinel-IR cleared this file” or “the code is safe”. Instead, report that the result was incomplete and explain which input you used. Depending on the file, check the syntax, make sure it is plain supported JavaScript, and try a smaller reproducible example. Even complete has strict limits: 1. It is a syntax-based structural report, not full semantic analysis. 2. It examines one file at a time. 3. It may not resolve aliases, computed properties, or behavior passed between modules. 4. It does not prove the application is secure. 5. It reduces some untrusted text passed onward, but it does not eliminate prompt injection. 6. It does not run your app or decide what an AI agent should do. Do not treat values such as world.confidence as calibrated probabilities. They are configuration or metadata fields, not a validated guarantee that the output is correct. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Phase 13](#phase-13-share-a-result-without-leaking-your-code) 🧭 Phase 13: Share a result without leaking your code Now for the part that matters if you want to publish a finding. The JSON report may contain names of imported packages, route paths, environment-variable names, operation names, risk signals, and the target filename you supplied. Those can reveal internal architecture. Even if a secret value is not intentionally extracted, never assume any generated report is automatically safe to publish. Before posting: 1. Open the report and review every field. 2. Remove or generalize private route names, internal package names, filenames, customer information, and anything that reveals a secret or proprietary design. 3. Do not publish private source code or a report from somebody else's code without permission. 4. Prefer the small synthetic sample from this guide when demonstrating basic behavior. 5. State clearly whether you tested the synthetic sample or your own project. 6. Include the exact version, Node version, command, expected result, actual result, and error text if something failed. Remove access tokens and personal filesystem paths. 7. Do not claim that a single smoke test proves the analyzer is secure or accurate in all cases. You can check the environment before writing your report: 🟦 DO THIS · Run in Termux node --version npm --version npm ls sentinel-ir Here is a report template you can adapt for DEV Community, GitLab, a discussion thread, or your own blog: 📝 COPY THIS TEMPLATE AND FILL IT IN Title: Sentinel-IR 0.1.1 Termux smoke test Device/OS: [Android version and device, if you want to share] Termux source: [F-Droid or official GitHub] Node.js: [output of node --version] Sentinel-IR: 0.1.1 Input: [synthetic sample / my own authorized JavaScript file] Command: node analyze.js sample.js Expected: analysisStatus=complete, route POST /upload, imports express and fs, env PORT Actual: [what really happened] Result: [PASS / FAIL / INCOMPLETE] Notes: [reproducible error or unexpected field, without secrets] Use your own DEV Community or GitLab account to publish your own test result. You do not need access to the maintainer's account. A useful bug report includes a minimal input that you are allowed to share, the exact version, what you expected, what happened, and whether analysisStatus was complete. ⬆️ [Contents](#quick-navigation) · ➡️ [Next: Troubleshooting](#troubleshooting-if-something-goes-wrong) 🧰 Troubleshooting: If Something Goes Wrong Repository errors when running pkg update > ⚠️ IF THIS FAILS: if Termux reports that a repository is unreachable or under maintenance, check your connection and change the Termux mirror: 🟦 DO THIS · Run in Termux termux-change-repo Choose an available official mirror in the interface, then run: 🟦 DO THIS · Run in Termux pkg update && pkg upgrade -y The Termux maintainers document repository and mirror fixes in their Package Management guide. Do not paste commands from unrelated download sites just because a mirror timed out. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) node: command not found Install Node.js again from Termux: 🟦 DO THIS · Run in Termux pkg update pkg install nodejs -y node --version npm --version > ⚠️ IF THIS FAILS: if the package manager itself is broken, resolve the repository issue first. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) Node.js is older than version 20 Run: 🟦 DO THIS · Run in Termux pkg update && pkg upgrade -y pkg install nodejs -y node --version > ⚠️ IF THIS FAILS: if the installed version is still below 20, do not continue with this release. Check the available packages in your Termux repository and follow the official Termux package guidance. Do not install two alternative Node packages blindly; they can conflict. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) npm install shows native build warnings or errors Sentinel-IR's native Tree-sitter packages are optional. This guide uses the bundled WASM parser, so retry the installation without optional dependencies: 🟦 DO THIS · Run in Termux cd "$HOME/sentinel-ir-termux-test" rm -rf node_modules package-lock.json npm install --save-exact --omit=optional sentinel-ir@0.1.1 This deliberately skips optional native parser packages. It does not skip the regular web-tree-sitter dependency needed by the WASM path. Then repeat Phase 5 and Phase 6. Only run the cleanup command in the dedicated test folder created by this guide. Do not run rm -rf node_modules in a project where you need to preserve the current installation. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) Cannot find module 'sentinel-ir' Check your location and installation: 🟦 DO THIS · Run in Termux cd "$HOME/sentinel-ir-termux-test" npm ls sentinel-ir > ⚠️ IF THIS FAILS: if it is missing, install the pinned release again: 🟦 DO THIS · Run in Termux npm install --save-exact sentinel-ir@0.1.1 ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) WebAssembly initialization failed First verify the package and WASM file are present: 🟦 DO THIS · Run in Termux cd "$HOME/sentinel-ir-termux-test" npm ls sentinel-ir web-tree-sitter ls -lh node_modules/sentinel-ir/wasm/ The published package should include tree-sitter-javascript.wasm. If the folder or file is missing, retry the install in the test directory. Check that the install finished and that the package version is 0.1.1. > ⚠️ IF THIS FAILS: if it still fails, keep the complete error message and your Node version. Do not replace the WASM file with an unrelated binary from a random website. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) analysisStatus is incomplete The package may have been unable to perform AST extraction, or the file did not parse cleanly. Check: 🟦 DO THIS · Run in Termux node --check sample.js Remember that the basic test expects JavaScript. TypeScript, JSX-heavy syntax, or other programming languages are outside the documented support claim. Do not treat fallback results as an equivalent structural parse. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) The expected route or import is missing First confirm that you are analyzing the sample from this guide, not another file: 🟦 DO THIS · Run in Termux cat sample.js node analyze.js sample.js > report.json Then inspect report.json. If the sample is exactly as shown, analysisStatus is complete, and the expected fact is still absent, preserve a sanitized copy of the sample and report the mismatch with package version and Node version. That is a useful reproducible issue. Do not change the expected output just to force a pass. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) npm cannot reach the registry Check connectivity, then retry: 🟦 DO THIS · Run in Termux npm ping npm view sentinel-ir@0.1.1 version > ⚠️ IF THIS FAILS: if the registry is temporarily unavailable on your connection, retry later or switch between Wi-Fi and mobile data. Do not post an installation timeout as an analyzer defect until the registry request itself works. ⬆️ [Troubleshooting index](#troubleshooting-if-something-goes-wrong) ✅ What Counts as a Successful Finish? By the end, all of these should be true: - node --version is at least 20. - npm ls sentinel-ir shows version 0.1.1. - The expected exported functions are present. - initializeWasm() finishes successfully. - node analyze.js sample.js writes report.json. - The report says analysisStatus: "complete" for the sample. - The verification script prints PASS: the sample produced the expected structural facts. - You understand that this is a smoke test, not a security certification. ✅ IF ALL CHECKS PASS: you have reproduced a small test of the published package on your phone. That is already useful: you did not need to trust a screenshot or a claim, because you ran the commands and inspected the output yourself. > ⚠️ IF THIS FAILS: if a check fails, that is not a personal failure. Keep the error, report the environment, and share only sanitized reproducible details. A failed reproducible test is more useful than a vague statement that something “doesn't work”. ⬆️ [Contents](#quick-navigation) · ➡️ [Final invitation](#one-final-invitation) 🚀 One Final Invitation Try it with the sample first. Then, if you have a JavaScript file you own and are comfortable inspecting, try that one. Check whether the facts match what the code actually contains. Look for missing facts and false positives. Tell me what you found, including the parts that did not work. This is a small structural analyzer, not an oracle. The interesting part begins when more people can run the same experiment, compare observations, and challenge the claims with evidence. Built and released from a phone-friendly workflow. Verified by your own terminal.

[Testing] linux-kernel-um in termux without root! This is a breakthrough, I’m finishing correcting details, you can even use docker inside the containers, and the performance is good, you can try it here.

OBS Studio running on android via termux without proot or root. Doesn't support browser source, camera (v4l2) and system wide screen capture though. Not the bestest experience but a lot better than using obs via proot . You can find patches that were made to this here : termux-packages#29412 And obs-mediacodec code here : lumaparallax/obs-mediacodec. Hope someday someone ports this as a native application.

An Android smartphone can function as a Network File System Version 3 (NFSv3) server using the open-source "nfsd" ("UNFS3, a User-Space NFSv3 Server") software as a native executable under Termux.