bad interpreter

What this page is for

bad interpreter is for a shell script fails because the shebang points to a path Termux does not have. Stay on this page if the error matches the title and the command output points to the same layer for bad interpreter.

Work on bad interpreter only after you can point to the exact clue in the terminal or browser output. For this guide, the main clues are bad, interpreter, bash, bin, and the page description is: Fix bad interpreter, /bin/bash not found, CRLF line endings, wrong shebangs, and copied shell scripts that fail on Android Termux.

Signs you are on the right page

• The same problem returns after a normal retry and it matches this topic: a shell script fails because the shebang points to a path Termux does not have.
• The output mentions bad, interpreter, bash, bin, or the failure happens immediately after a command connected to bad interpreter.
• You can reproduce the bad interpreter problem with one short test command instead of launching the whole project again.
• Use /data/data/com.termux paths or /usr/bin/env when appropriate.

Why it happens in Termux

bad interpreter belongs to the phone workflow layer. In Termux, that layer can change because Android paths, package state, working folders, cached browser files, or Git settings are not shared the way they are on a desktop Linux system for bad interpreter.

• For bad interpreter, look for bad, interpreter, bash, bin in the first useful output line. That line decides whether you should fix a path, dependency, permission, port, or repository setting for bad interpreter.
• Projects grow without a folder plan, so outputs, code, backups, and downloaded files get mixed for bad interpreter.
• The same command is changed many times without a note of what worked.
• Large phone projects become slow because logs, caches, zips, and test folders stay in the active tree for bad interpreter.

Copyable command

Run this from the folder that belongs to bad interpreter. Replace placeholder names before pressing Enter.

head -n 1 script.sh
sed -i "s|^#!/bin/bash|#!/usr/bin/env bash|" script.sh
pkg install dos2unix -y
dos2unix script.sh
chmod +x script.sh
./script.sh

How to read the output

1. head -n 1 script.sh — Runs a focused check for bad interpreter; compare its output with the symptom before changing anything else.
2. sed -i "s|^#!/bin/bash|#!/usr/bin/env bash|" script.sh — Runs a focused check for bad interpreter; compare its output with the symptom before changing anything else.
3. pkg install dos2unix -y — Installs the Termux package named in the command; read the package name before pressing Enter.
4. dos2unix script.sh — Runs a focused check for bad interpreter; compare its output with the symptom before changing anything else.
5. chmod +x script.sh — Changes execute permission for scripts that must run directly for bad interpreter.
6. ./script.sh — Runs a focused check for bad interpreter; compare its output with the symptom before changing anything else.

Fix it in this order

1. Copy the exact bad interpreter message before changing anything. Keep the command, folder, and first useful error line together.
2. Run only the diagnostic part of the command block. If it fails early, do not continue to the later lines yet.
3. Fix the layer named by the first useful output line: path, permission, package, Python environment, Git state, or browser URL for bad interpreter.
4. Retest with the shortest command that originally failed. Do not restart the whole project until the small test works.
5. When it works, write down the final command in your notes or README so the same bad interpreter problem is easier next time.

Common mistakes

• Jumping from bad interpreter to a full reinstall even though one smaller check can identify the failing layer.
• Building a big script before the tiny test command works.
• Keeping only one copy of an important project.
• Writing instructions after you forget the exact setup steps.

Before you leave the page

• The original bad interpreter output should be gone, shorter, or replaced by a different and more specific error.
• You should know which folder you were in and which command changed the result for bad interpreter.
• You should have a backup before deleting files, overwriting repositories, or changing working scripts for bad interpreter.

Related Assistance pages