可执行文件是否可以动态解析其在文件系统上的位置或其实际的“休息位置”，而只是用户的工作目录？

Question

如果我有一个可执行文件/usr/bin并在我位于~/dev/wikis/（即user@HAL:~/dev/wikis$ the_executable）时调用它，可执行文件中的ioutil.ReadFile("file.txt")函数将查找/home/user/dev/wikis/file.txt，但是否可以/usr/bin/file.txt在用户或开发人员事先不知道可执行文件的情况下使其查找位于/usr/bin（也可以位于/home/user/dev/my_program/the_executable）？

然后添加了一层复杂性，另一种情况，说我把从可执行符号链接在/usr/bin与可执行文件实际上是的“来源” /home/user/dev/my_program/the_executable，我想程序知道/home/user/dev/my_program/在这种情况下，动态的，而不是/usr/bin.

简而言之：可执行文件如何动态解析其在文件系统上的位置或其实际“休息位置”与用户的工作目录（可以很容易地通过os.Getwd()以及ioutil.ReadFile使用其他命令或使用类似的东西来解析路径） ）。

我最好的办法是我必须获得正在运行的程序 ( os.Getpid)的 PID，然后以某种方式使用该整数来访问有关在该 PID 下运行的程序实例的信息，希望该信息包含其目录的字符串，我可以然后使用。

Answer 1

在Linux（和其他Unixy系统也许），你会发现一个符号链接到实际运行可执行文件作为pid下/proc/pid/exe，检查一个会给你想要的东西，如果它是一个二进制。如果它是某种脚本，那可能只会给解释器。但请注意，完全有可能启动一个进程并在它运行时删除可执行文件，留下悬空链接或什么都不留下。

Answer 2

这将取决于语言，但据我所知，大多数编程语言都可以获取程序的“基本名称”（例如 helloworld）或完整路径（例如 /usr/bin/helloworld）。通常这作为程序的第一个参数提供，由操作系统/运行时库/解释器等插入。 例如，在 C 中，argv[0]（因为我们在 C 中从 0 开始计数）给出当前的名称程序，但是调用过程会初始化这个特殊参数，因此确切的格式可能会有所不同，并且在 bash 中， $0 将扩展为执行时给定的脚本路径（我认为）。从这里：https : //gobyexample.com/command-line-arguments, “os.Args 提供对原始命令行参数的访问。请注意，此切片中的第一个值是程序的路径，而 os.Args[1:] 保存程序的参数。” 所以看起来你不需要担心 /proc 但如果你有兴趣，我如何在 C 中找到可执行文件的位置？

Answer 3

导出的变量os.Args（它是一个切片：）[]string保存程序参数，它的第一个元素是带有完整路径的可执行文件名称。如果可执行文件不是符号链接，您可以使用path或filepath包来获取可执行文件的文件夹，如下所示：folder := filepath.Dir(os.Args[0])并且您可以使用os.Readlink()来解析符号链接。并且要测试您的可执行文件是否是符号链接，您可以使用os.Lstat()which 不尝试跟随链接（而不是os.Stat()）。所以你的最终版本应该是这样的：s := os.Args[0]fi, err := os.Lstat(s)if err != nil {    panic(err) // Failed to get stats}// Check if it's a symlink and if so, try to resolve itif fi.Mode()&os.ModeSymlink != 0 {    if s, err = os.Readlink(s); err != nil {        panic(err) // Failed to resolve symlink    }}s = filepath.Dir(s) // We only want the folder part