几种看上去都可行的实现方式，又无意间加宽了服务商与用户之间的间隔，朝着有利于服务商发展的方向，无可非议；然而，以用户需求为核心，仍然是一个基本原则（黑客与画家，阮一峰译）。
背景与问题
按照AppImage的包组成模式，它总是有一个AppRun文件，作为启动应用的脚本文件。类似的，在中标/银河麒麟等操作系统上开发的应用，为了保持应用依赖库、配置环境变量等信息的专有和最小范围，在生成应用的可执行文件（比如app-tests）后，我们通常也会为它编写一个对应的启动脚本（比如run.sh），然而，在中标麒麟V5上编写的run.sh，在文件管理器（caja）中，双击可以运行（指最终成功运行app-tests）；而在最新的银河麒麟V10sp1上，同样的run.sh文件，在文件管理器（peony）中，双击却无法运行。
中标麒麟V5中的文件结构示例：
/home/user/app-tests
app-tests
run.sh
中标麒麟V5中的run.sh内容示例：
#!/bin/sh
./app-tests
分析
中标麒麟V5上，在caja文件管理器里，双击run.sh后，对脚本运行的目录，是指的当前目录。
在银河麒麟V10上，其使用了自研的peony文件管理器，双击run.sh后，对脚本运行的目录，像是一个不可预料的状态（也有可能其有一个内部的约定，但至少是有两种情形：直接运行文件管理后，双击run.sh，脚本里的$(pwd)会输出“/home/user”结果；而在桌面（/home/user/桌面）由控制台里/usr/bin/peony启动文件管理器后，双击run.sh，脚本里的$(pwd)会输出“/home/user/桌面”结果）。
而我们不想再继续深究peony当前的实现情况，所以采用绝对路径来运行应用，是个方案。
解决
无论是中标麒麟V5、还是银河麒麟V10，均使用以下同一套脚本（run.sh），来保障运行的一致和正确性：
#!/bin/sh
#获取脚本的实际路径
scriptRunFullPath=”$(readlink -f “${0}”)”#认为脚本实际路径，与可执行程序的路径，是同一个目录
scriptDir=”$(dirname “${scriptRunFullPath}”)”#根据实际设置
appName=”app-tests”
appDir=”${scriptDir}”exec “${appDir}/${appName}”
其他
这明显是一个小问题。然而，从界定上，它是一个编程问题，还是一个产品功能一致性问题，还是双方都有问题，难于划分。