我正在写一个'C'程序，它会调用system（）来执行其他程序。构造命令字符串时，最好是显式地给出被调用程序的完整路径，还是应该给出可执行文件名，让shell使用PATH环境变量解析它的位置？
我正在调用的程序都是单个程序包的一部分，我从预处理程序定义获得了安装目录的路径。如果多个已安装的程序共享同一名称，则提供显式路径似乎可以避免可能发生的错误。然而，它使得构建命令字符串变得更复杂，如果用户在安装后移动程序，一切都会破坏。
是否有广泛接受的最佳做法？
[澄清]
我正在使用autoconf / automake来生成分发。提供安装目录的预处理器定义由makefile创建。它反映了用户对configure comamnd line或make命令行中指定的安装目录的选择。我确实注意到使用环境变量来指定二进制文件的位置。这似乎是一个不必要的痛苦，让用户重建只是为了改变二进制文件的位置。
答案 0 :(得分：3)
最佳做法是永远不要假设您在构建时知道安装目录。让您的用户决定安装和工作的位置。
这意味着您需要使用其他机制找出程序所在的位置。如果您的平台没有为您提供找出可执行文件所在位置的方法，请考虑使用环境变量或命令行参数来允许用户指定实际路径。您可以使用您对正常安装位置的了解作为后备选项。
对于您的实际问题，如果您可以构建程序的绝对路径（使用除预处理程序指令之外的其他机制） - 请使用它。否则，回到让系统找到你。
答案 1 :(得分：1)
最佳做法是不要假设您正在安装的系统。如果您只是让用户选择，您可以充分利用这两个方面。使您调用应用程序首选项的命令或要求在环境中定义路径：
PATH_TO_TOOL1=foo
PATH_TO_TOOL2=/usr/bin/bar
当然，如果未定义变量或未设置首选项，您可以回退到某种默认值。编写应用程序以提高灵活性始终是最佳选择！
答案 2 :(得分：1)
您绝对应该让用户使用环境变量为已安装的二进制文件指定路径。并非所有系统都是相同的，很多人都希望将他们的高管放在不同的地方。
我能想到的最好的例子是人们进行本地安装与系统安装。如果您的程序安装在用户必须设置的主目录中，并且env变量以说明二进制文件的复制位置。
答案 3 :(得分：1)
如果你完全确定路径名，并且它们不是“众所周知的”命令（例如，Unix上的POSIX shell实用程序是“众所周知的”），你应该指定路径名，否则不要指定完整路径，或让用户使用环境变量控制它。
实际上，您可以编写像int my_system(const char *);之类的函数，它可以为您创建路径的前缀。如果稍后您确定这是一个坏主意，那只是让my_system()与system()相同。
答案 4 :(得分：0)
我不确定这是否是最佳做法，但在这些情况下我做的是将C代码写入扩展PATH环境变量以包含最后的安装目录。然后我只使用PATH。这样，如果用户PATH想要覆盖我相信安装内容的地方，它可以 - 但如果软件安装在偏远的地方，我可以在不强迫我的用户的情况下调用它将目录放在$PATH上。
请注意，只要C程序运行，扩展PATH就会持续;我不打算改变持久性PATH。