为什么在将 x-shellscript 转换为 x-executable 后，参数 $0 只给我基本名称而不是完整路径？

Question

我的问题是该参数$0给出了与 相同的结果${0##*/}，这是在使用 SHC 程序将 x-shellscript 转换为 x-executable 之后发生的！

操作系统：Debiab-8.2-jessie SHC 版本：3.8.7 cmd 使用： shc -f script.bash

编译后的 script.x 驻留在额外的 bin 路径中（sudo 不知道）。 注意我创建了一个 hello world 程序来打印参数 $0，它总是给我基本名称！

我的脚本文件包含：

#!/bin/bash
((!EUID)) || exec sudo "$0"
# shellcode ...

当我执行它时，我得到这个：

须藤：脚本名称：找不到命令

检查后我发现该参数$0与x 可执行文件相同${0##*/}或$(basename $0)位于其中！

如果不在脚本中放置绝对路径，我该如何处理？或者当我使用 SHC 将 shell 编译为 x 可执行文件时我应该知道什么？

Answer 1

为什么是 SHC？

首先，考虑到您的“业余爱好者”动机，您为什么要使用 SHC？以下是他们自己描述的摘录：

执行后，编译后的二进制文件将使用 shell -c 选项解密并执行代码。不幸的是，它不会像真正的 C 程序那样为您带来任何速度提升。

编译后的二进制文件仍将依赖于在 shell 代码的第一行（即 #!/bin/sh）中指定的 shell，因此 shc 不会创建完全独立的二进制文件。

SHC 的主要目的是保护您的 shell 脚本不被修改或检查。

• 我的意见（我会保持简短）：即使你的动机是防止修改的“主要目的”，一个温和的人仍然可以恢复（并因此修改）原始脚本！SHC 本质上通过 obscurity提供安全性，当用作主要安全手段时，这是一种经常被嘲笑的策略。如果这听起来没有帮助，那么我建议放弃 SHC 并像绝大多数其他人一样简单地使用 shell 脚本。如果您的 shell 脚本需要真正的安全性，我建议您提出一个具体的问题，不要使用 SHC 或“编译器”。

特定的 $0 问题

我从这个页面下载了 SHC 3.8.9只是为了试试这个。

我无法在 Ubuntu 14.04 LTS 上重现该问题。

#!/bin/bash
echo "Hello, world. My name is \`$0'"

测试运行

$ ./shc -f my_test.bash
$ ~/path/to/my_test.bash.x

Hello, world. My name is `~/path/to/my_test.bash.x'

所以，很明显，我们的系统不同。如果您发布有关操作系统、SHC 版本以及用于“编译”它的特定shell 脚本和shc命令行的更多详细信息，我可以尝试更新此答案。

为什么需要路径？

为什么你的脚本需要知道它的路径？您是否使用脚本存储文件？如果用户没有指定，它是否“默认”操作它运行的目录？这些事情是否是好主意是一个意见问题，但了解您的动机可能有助于缩小这个答案的范围。

如何获取当前目录

该pwd命令获取当前目录。在许多情况下，您可以使用以下内容组合脚本的完整路径（假设它使用显式相对路径运行）：

realname="`pwd`/$0"

...这将导致一个值，如：

/path/to/script/./yourscript.bash.x

额外的./只是意味着“当前目录”，所以虽然它可能在外观上很不幸，但它不会对结果产生负面影响。

如果脚本只是在您的 中$PATH，那么您将需要使用which而不是pwd，但我们已经超出了原始问题的范围，在这里，所以我将简单地提到确定路径名可能是一个棘手的过程，特别是如果您需要以安全的方式这样做，那么最好将其留给另一个问题，并附上这些方面的特定问题陈述。