我如何在C中找到可执行文件的位置？
这个问题在这里已经有了答案：
总结：
在使用/proc Unix上，真正直接和可行的方法是：
readlink("/proc/self/exe", buf, bufsize) （Linux）
readlink("/proc/curproc/file", buf, bufsize) （FreeBSD）
readlink("/proc/self/path/a.out", buf, bufsize) （Solaris）
在没有/proc Unix上（即如果以上失败）：
如果argv [0]以“/”（绝对路径）开头，则为路径。
否则，如果argv [0]包含“/”（相对路径），则将其追加到cwd（假设它尚未更改）。
否则，在$PATH搜索可执行文件argv[0] 。
之后，检查可执行文件是否实际上不是符号链接可能是合理的。 如果它解决了它相对于symlink目录。
这个步骤在/ proc方法中是不必要的（至少对于Linux来说）。 那里的proc符号链接直接指向可执行文件。
请注意，它由调用进程正确设置argv[0] 。 这是正确的大多数时候，但有时，调用过程不可信（例如setuid可执行文件）。
在Windows上：使用GetModuleFileName(NULL, buf, bufsize)
如果您使用的是Windows，请使用GetModuleFileName（）函数。
请注意，以下评论仅限unix。
对这个问题的迂回回答是，在所有情况下都没有正确回答这个问题的一般方法。 正如你发现的那样，argv [0]可以由父进程设置为任何东西，因此不需要与程序的实际名称或其在文件系统中的位置无关。
但是，以下启发式经常起作用：
/ ，则使用getcwd（）确定当前工作目录，然后向其附加argv [0]。 请注意，所有这些都可以通过调用相关程序的过程来绕过。 最后，您可以使用特定于linux的技术，例如emg-2中提到的技术。 其他操作系统上可能有相同的技术。
即使假设上面的步骤给你一个有效的路径名，你仍然可能没有你真正想要的路径名（因为我怀疑你实际上想要做的是找到某个配置文件）。 硬链接的存在意味着您可以有以下情况：
-- assume /app/bin/foo is the actual program
$ mkdir /some/where/else
$ ln /app/bin/foo /some/where/else/foo # create a hard link to foo
$ /some/where/else/foo
现在，上面的方法（包括，我怀疑，/ proc / $ pid / exe）会将/some/where/else/foo作为程序的真正路径。 而且，实际上，这是该计划的真正途径，而不是你想要的。 请注意，在实践中比硬链接更常见的符号链接不会出现此问题。
尽管这种方法原则上不可靠，但在大多数情况下，它在实践中运作良好。
链接地址: http://www.djcxy.com/p/54701.html