解决 `sh: 1: sqlmap: not found`：HackingTool 环境变量注入失效排雷

这是 HackingTool Issue 区最长青、也最让新手崩溃的问题：明明在终端输入 sqlmap 跑得飞起，但在 HackingTool 的交互菜单里选了“1”运行，它偏偏给你甩出一句 sh: 1: sqlmap: not found。

很多人的第一反应是重装，或者疯狂在 install.sh 上点鼠标。作为架构师，我必须告诉你：这背后隐藏着 Linux 一个极其阴险的机制——非交互式 Shell 的路径丢失。

💡 报错现象总结：用户在 Kali Linux 中手动执行工具正常，但在 HackingTool 内部调用时提示 command not found。根本原因在于 core.py 使用子进程调用命令时，未能加载用户的 .bashrc 或 .zshrc 环境变量，导致通过 Go 安装（~/go/bin）或手动安装在非标准路径的工具全部处于“失联”状态。

深度排雷：os.system 与 PATH 的断裂

HackingTool 的核心逻辑中，大量使用了 Python 的 os.system() 函数。这个函数在执行时会 fork 出一个底层的子 Shell（通常是 /bin/sh）。

这里就是坑所在： 这个子 Shell 是非交互且非登录的。这意味着它在启动时根本不会去读你的 .bashrc 或 .zshrc。如果你把 sqlmap 或是 nuclei 装在了自己的用户目录下，而没有软链接到 /usr/bin 这种全局“硬路径”，子进程必然会空手而归。

# 存在路径隐患的源码实现
def run(self):
    # 痛点：这里运行的是底层 sh，它根本不知道你的自定义 PATH 在哪里
    # 它只认系统最原始的那个环境变量
    os.system("sqlmap -u " + target)

下表展示了不同安装方式在 HackingTool 内部的“生还率”：

安装方式	实际路径示例	HackingTool 能否直接调用	失败原因
Apt 安装	/usr/bin/sqlmap	是	在全局标准路径中
Go Install	~/go/bin/nuclei	否	子进程不加载用户自定义 PATH
Git Clone	~/.hackingtool/...	否	未建立全局软链接
Python Pip	~/.local/bin/...	否	权限隔离导致路径不可见

填坑实战：原生态的路径硬编码

如果你现在急着要用，最快的“笨办法”是去改 core.py，把每一个命令都改成绝对路径。

比如，把所有的 sqlmap 替换成 /usr/bin/sqlmap，把所有的 nuclei 替换成 /home/kali/go/bin/nuclei。但是，想象一下，HackingTool 里集成了两百多个工具，如果你每个都去手动对齐路径，不仅效率低得令人发指，而且一旦你换台机器，这套代码就彻底废了。这种硬编码（Hardcoding）是软件架构中的大忌。

降维打击：获取 GitCode 自动路径对齐补丁

别再把生命浪费在改路径这种琐事上了。为了彻底打通 HackingTool 的“任督二脉”，我已经在 GitCode 上发布了一个 env_bridge.py 补丁。

这套方案通过以下技术手段解决问题：

1. 全路径动态捕获：补丁在主程序启动时，会自动读取当前用户完整的所有活跃路径。
2. 子进程强制注入：弃用 os.system，改用更底层的 subprocess 模块，并在调用瞬间将捕获到的 PATH 强制注入到子进程环境。
3. 软链接自修复：自动识别系统中安装位置异常的渗透工具，并提示一键建立全局映射。

[前往 GitCode 领取《全路径感知执行补丁》]

架构师的职责就是让复杂的环境变透明。去 GitCode 拿走这份补丁，别再让那些低级的路径报错挡住你的渗透思路。