What causes "Exit code = {}" in bee-san/RustScan?

Run the script standalone to reproduce and fix the failing logic inside the script

Exit code =

Error message

Exit code = {}

What it means

After a script process finishes, execute_script inspects its exit code; any non-zero code becomes the anyhow error 'Exit code = {code}'. This is not a rustscan bug — the script itself ran and failed, and rustscan surfaces the script's own exit status to the caller.

Solutions

Run the script standalone to reproduce and fix the failing logic inside the script
Check the script's stderr/debug logs (rustscan debug flag) for the interpreter's error message
Ensure the script exits 0 on success paths (avoid using non-zero for soft outcomes)
Verify the interpreter and dependencies the script needs are installed in the environment

Example fix

// before: scan.sh
nmap -p $1 $2   # exits non-zero if host down
// after
nmap -p $1 $2 || true

Defensive patterns

Strategy: try-catch

Validate before calling

// Smoke-test the script standalone before using it in rustscan
fn script_smoke_ok(call_format: &str) -> bool {
    std::process::Command::new("sh").arg("-c").arg(call_format)
        .output().map(|o| o.status.success()).unwrap_or(false)
}

Try / catch

match script.run() {
    Ok(out) => println!("{out}"),
    Err(e) if e.to_string().starts_with("Exit code = ") => {
        let code = e.to_string().trim_start_matches("Exit code = ");
        eprintln!("Script itself failed with code {code}; inspect script stderr/debug logs");
    }
    Err(e) => return Err(e),
}

Prevention

Exit 0 on success paths in your scripts; reserve non-zero for real failures
Test each script manually with representative arguments before wiring into rustscan
Check interpreter/dependency availability in the target environment
Enable rustscan debug logging to capture the script's own stderr

When it happens

Trigger: Any executed script (bash/python/perl/custom call_format) returns a non-zero exit status — e.g. a script exits 1 on a failed scan or an unhandled interpreter error.

Common situations: Scripts with syntax errors or missing interpreter modules; nmap-style helper scripts exiting non-zero when a target is unreachable; scripts that use non-zero codes to signal 'no results', which rustscan treats as failure.

Related errors

AI-assisted analysis of bee-san/RustScan@e9dadb4a30 (2026-09-02). Data as JSON: /api/errors/246b1d5dc9b02399. Report an issue: GitHub.

Appendix: source

Thrown at src/scripts/mod.rs:312

            let status = output.status;

            let es = match status.code() {
                Some(code) => code,
                _ => {
                    #[cfg(unix)]
                    {
                        status.signal().unwrap()
                    }

                    #[cfg(windows)]
                    {
                        return Err(anyhow!("Unknown exit status"));
                    }
                }
            };

            if es != 0 {
                return Err(anyhow!("Exit code = {}", es));
            }
            Ok(String::from_utf8_lossy(&output.stdout).into_owned())
        }
        Err(error) => {
            debug!("Command error {error}",);
            Err(anyhow!(error.to_string()))
        }
    }
}

pub fn find_scripts(path: PathBuf) -> Result<Vec<PathBuf>> {
    if path.is_dir() {
        debug!("Scripts folder found {}", &path.display());
        let mut files_vec: Vec<PathBuf> = Vec::new();
        for entry in fs::read_dir(path)? {
            let entry = entry?;
            files_vec.push(entry.path());
        }

View on GitHub (pinned to e9dadb4a30)