basename "$0" 在脚本中常失效，因 $0 未标准化：遇空格不加引号会拆分、软链接返回链接名而非目标名、相对路径不解析；推荐用 readlink -f "$0" 或 realpath "$0" 归一化后再 basename。
直接用 basename 提取文件名没问题，但脚本里硬写 basename $0 很可能出错——路径含空格、符号或软链接时结果就不可靠。
为什么 basename $0 在脚本中经常失效
因为 $0 是原始调用路径，没做任何标准化处理。比如用户用 ./script.sh、/home/user/../bin/script.sh 或软链接调用，basename $0 都只简单截最后一段，不解析真实路径也不处理空格。
- 若脚本路径含空格（如
/path/to/my script.sh），未加引号的$0会被 shell 拆成两个参数，basename只收到/path/to/my，结果完全错误 - 软链接场景下，
basename $0返回的是链接名，不是目标脚本名（有时这反而是你想要的，但多数时候不是） -
basename默认按/分割，对 Windows 风格路径（\）或 URL（http://）无意义，但脚本里混用时容易误判
安全提取当前脚本真实文件名的推荐写法
关键不是换函数，而是先归一化路径再取名。用 readlink -f 解析软链接并转为绝对路径，再交给 basename。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
SCRIPT_NAME=$(basename "$(readlink -f "$0")")
-
"$0"加双引号，确保含空格路径不被拆分 -
readlink -f会递归解析所有软链接，并补全相对路径为绝对路径（注意：macOS 不带-f，需用greadlink -f或改用realpath） - 外层
basename此时输入是干净的绝对路径，不会出错
想保留软链接名？那就别用 readlink -f
有些场景你确实需要知道“用户怎么调用的”，比如日志记录或权限检查，这时反而是 basename "$0" 更合适——但必须加引号。
- 仅用
basename "$0"：返回调用时的最后一段（可能是链接名、.、甚至空字符串） - 用
basename "${0##*/}"是等效替代，纯 shell 内置，不依赖readlink，但同样不解析软链接 - 如果
$0是-bash（交互式 shell 启动脚本），${0##*/}会返回-bash，而basename "$0"也会一样——这点常被忽略
更严谨的方案：兼容 macOS 和 Linux
Linux 常用 readlink -f，macOS 默认没有；realpath 是 GNU coreutils 工具，macOS 需 brew install coreutils，装完命令是 grealpath。
if command -v realpath >/dev/null 2>&1; then
SCRIPT_NAME=$(basename "$(realpath "$0")")
elif command -v readlink >/dev/null 2>&1 && readlink -f / >/dev/null 2>&1; then
SCRIPT_NAME=$(basename "$(readlink -f "$0")")
else
SCRIPT_NAME=$(basename "$0")
fi
真正麻烦的不是语法，而是不同环境对“当前脚本路径”的定义差异——有人要真实路径，有人要调用路径，有人还要兼容容器内挂载路径。选哪个，得看你的日志、配置加载、或权限校验逻辑到底依赖什么。
