获取可执行文件的路径
我知道这个问题以前已经被问过,但我仍然没有看到令人满意的答案,或者明确的“不,这不能做到”,所以我会再问一次!
我想要做的就是以独立于平台的方式获取当前运行的可执行文件的路径,无论是绝对路径还是相对于调用可执行文件的位置的相对路径。我虽然 boost::filesystem::initial_path 是我的麻烦的答案,但这似乎只能处理问题的“平台无关”部分 - 它仍然返回调用应用程序的路径。
作为一些背景知识,这是一个使用 Ogre 的游戏,我正在尝试使用 Very Sleepy 来分析它,它从自己的目录运行目标可执行文件,所以当然在加载时游戏找不到配置文件等并立即崩溃。我希望能够向其传递配置文件的绝对路径,我知道配置文件将始终与可执行文件一起存在。 Visual Studio 中的调试也是如此 - 我希望能够运行 $(TargetPath) 而无需设置工作目录。
I know this question has been asked before but I still haven't seen a satisfactory answer, or a definitive "no, this cannot be done", so I'll ask again!
All I want to do is get the path to the currently running executable, either as an absolute path or relative to where the executable is invoked from, in a platform-independent fashion. I though boost::filesystem::initial_path was the answer to my troubles but that seems to only handle the 'platform-independent' part of the question - it still returns the path from which the application was invoked.
For a bit of background, this is a game using Ogre, which I'm trying to profile using Very Sleepy, which runs the target executable from its own directory, so of course on load the game finds no configuration files etc. and promptly crashes. I want to be able to pass it an absolute path to the configuration files, which I know will always live alongside the executable. The same goes for debugging in Visual Studio - I'd like to be able to run $(TargetPath) without having to set the working directory.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(26)
据我所知,没有跨平台的方法。
对于 Linux:将
"/proc/self/exe"
传递给 <代码>std::filesystem::canonical 或readlink< /代码>
。
Windows:将 NULL 作为模块句柄传递给
GetModuleFileName
。There is no cross platform way that I know.
For Linux: pass
"/proc/self/exe"
tostd::filesystem::canonical
orreadlink
.Windows: pass NULL as the module handle to
GetModuleFileName
.boost::dll::program_location 函数是我所知道的获取正在运行的可执行文件路径的最佳跨平台方法之一。 DLL 库在 1.61.0 版本中添加到 Boost 中。
以下是我的解决方案。我已经在 Windows、Mac OS X、Solaris、Free BSD 和 GNU/Linux 上测试过它。
它需要 Boost 1.55.0 或更高版本。它直接使用 Boost.Filesystem 库 Boost.Locale 库和 <间接使用 href="http://www.boost.org/doc/libs/1_66_0/libs/system/doc/index.html" rel="noreferrer">Boost.System 库。
src/executable_path.cpp
src/detail/executable_path_internals.cpp
include/boost/executable_path.hpp
include/boost/detail/executable_path_internals.hpp
我有一个完整的项目,包括一个测试应用程序和 CMake 构建文件,可在 SnKOpen - /cpp/executable_path/trunk。这个版本比我在这里提供的版本更完整。它还支持更多平台。
我在以下四种场景中在所有受支持的操作系统上测试了该应用程序。
在所有四种情况下,executable_path 和executable_path_fallback 函数都可以工作并返回相同的结果。
注释
这是此问题的更新答案。我更新了答案以考虑用户的意见和建议。我还在 SVN 存储库中添加了一个项目的链接。
The boost::dll::program_location function is one of the best cross platform methods of getting the path of the running executable that I know of. The DLL library was added to Boost in version 1.61.0.
The following is my solution. I have tested it on Windows, Mac OS X, Solaris, Free BSD, and GNU/Linux.
It requires Boost 1.55.0 or greater. It uses the Boost.Filesystem library directly and the Boost.Locale library and Boost.System library indirectly.
src/executable_path.cpp
src/detail/executable_path_internals.cpp
include/boost/executable_path.hpp
include/boost/detail/executable_path_internals.hpp
I have a complete project, including a test application and CMake build files available at SnKOpen - /cpp/executable_path/trunk. This version is more complete than the version I provided here. It is also supports more platforms.
I have tested the application on all supported operating systems in the following four scenarios.
In all four scenarios, both the executable_path and executable_path_fallback functions work and return the same results.
Notes
This is an updated answer to this question. I updated the answer to take into consideration user comments and suggestions. I also added a link to a project in my SVN Repository.
C++17、windows、unicode、使用文件系统新 api:(
重要:将
wmain
与wchar_t**
一起使用 - 不要混合 < code>main 和wchar_t**
。对于 cmake 项目,使用add_definitions(-DUNICODE -D_UNICODE)
启用 unicode。怀疑这个解决方案应该是可移植的,但不知道 unicode 在其他操作系统上是如何实现的。
仅当您使用输出目录上层文件夹引用(“..”)来简化路径时,才需要weakly_canonical。如果您不使用它 - 将其删除。
如果您是从动态链接库(.dll /.so)进行操作,那么您可能没有argv,那么您可以考虑以下解决方案:
application.h:
application.cpp:
C++17, windows, unicode, using filesystem new api:
(Important: Use
wmain
withwchar_t**
- don't mixmain
withwchar_t**
. For cmake projects enable unicode usingadd_definitions(-DUNICODE -D_UNICODE)
).Suspect this solution should be portable, but don't know how unicode is implemented on other OS's.
weakly_canonical is needed only if you use as Output Directory upper folder references ('..') to simplify path. If you don't use it - remove it.
If you're operating from dynamic link library (.dll /.so), then you might not have argv, then you can consider following solution:
application.h:
application.cpp:
这种方式使用boost + argv。您提到这可能不是跨平台的,因为它可能包含也可能不包含可执行文件名称。那么下面的代码应该可以解决这个问题。
以下代码获取当前工作目录,这可能会满足您的
需要
刚刚意识到
basename(
) 已被弃用,因此必须切换到.stem()
This way uses boost + argv. You mentioned this may not be cross platform because it may or may not include the executable name. Well the following code should work around that.
The following code gets the current working directory which may do what you need
Note
Just realized that
basename(
) was deprecated so had to switch to.stem()
我不确定 Linux 是否如此,但在 Windows 上尝试一下:
I'm not sure about Linux, but try this for Windows:
这就是我最终得到的
头文件如下所示:
实现
This is what I ended up with
The header file looks like this:
Implementation
对于 Windows:
GetModuleFileName
- 返回 exe 路径 + exe 文件名删除文件名
PathRemoveFileSpec
For windows:
GetModuleFileName
- returns the exe path + exe filenameTo remove filename
PathRemoveFileSpec
QT 提供了操作系统抽象 QCoreApplication::applicationDirPath()
QT provides this with OS abstraction as QCoreApplication::applicationDirPath()
如果使用 C++17,可以执行以下操作来获取可执行文件的路径。
以上答案已在 Debian 10 上使用 G++ 9.3.0 进行了测试
If using C++17 one can do the following to get the path to the executable.
The above answer has been tested on Debian 10 using G++ 9.3.0
这是 Windows 特定的方式,但它至少是您答案的一半。
GetThisPath.h
GetThisPath.cpp
mainProgram.cpp
我建议使用平台检测作为预处理器指令来更改调用 < 的包装函数的实现对于每个平台,code>GetThisPath。
This is a Windows specific way, but it is at least half of your answer.
GetThisPath.h
GetThisPath.cpp
mainProgram.cpp
I would suggest using platform detection as preprocessor directives to change the implementation of a wrapper function that calls
GetThisPath
for each platform.使用 args[0] 并查找“/”(或“\\”):
编辑:
如果 '/' 不存在,则 pos==-1 所以结果是正确的。
Using args[0] and looking for '/' (or '\\'):
EDITED:
If '/' does not exist, pos==-1 so the result is correct.
对于 Windows,您可以使用 GetModuleFilename()。
对于 Linux,请参阅 BinReloc(旧的、已失效的 URL) 镜像href="https://github.com/datenwolf/binreloc" rel="nofollow noreferrer">datenwolf 的 GitHub 存储库中的 BinReloc。
For Windows you can use GetModuleFilename().
For Linux see
BinReloc (old, defunct URL)mirror of BinReloc in datenwolf's GitHub repositories.这可能是最自然的方法,同时涵盖了大多数主要桌面平台。我不确定,但我相信如果您更改平台宏检查以覆盖所有 BSD,这应该适用于所有 BSD,而不仅仅是 FreeBSD。如果我有时间安装 Solaris,我一定会将该平台添加到受支持的列表中。
在 Windows 上具有完整的 UTF-8 支持,但并不是每个人都足够关心这一点。
procinfo/win32/procinfo.cpp
procinfo/macosx/procinfo.cpp
procinfo/linux/procinfo.cpp
procinfo/freebsd/procinfo.cpp
procinfo/procinfo.cpp
procinfo/procinfo.h
这允许获取几乎所有可执行文件的完整路径任何进程 ID,除了 Windows 上有一些具有安全属性的进程根本不允许它,所以所见即所得,这个解决方案并不完美。
为了更准确地解决问题,您可以这样做:
procinfo.cpp
使用以下命令构建上述文件结构:
procinfo.sh
用于下载上面列出的文件的副本:
对于更多与跨平台进程相关的优点:
https://github.com/time-killer-games/enigma-dev
请参阅自述文件以获取所包含的大部分功能的列表。
This is probably the most natural way to do it, while covering most major desktop platforms. I am not certain, but I believe this should work with all the BSD's, not just FreeBSD, if you change the platform macro check to cover all of them. If I ever get around to installing Solaris, I'll be sure to add that platform to the supported list.
Features full UTF-8 support on Windows, which not everyone cares enough to go that far.
procinfo/win32/procinfo.cpp
procinfo/macosx/procinfo.cpp
procinfo/linux/procinfo.cpp
procinfo/freebsd/procinfo.cpp
procinfo/procinfo.cpp
procinfo/procinfo.h
This allows getting the full path to the executable of pretty much any process id, except on Windows there are some process's with security attributes which simply will not allow it, so wysiwyg, this solution is not perfect.
To address what the question was asking more precisely, you may do this:
procinfo.cpp
Build the above file structure with this command:
procinfo.sh
For downloading a copy of the files listed above:
For more cross-platform process-related goodness:
https://github.com/time-killer-games/enigma-dev
See the readme for a list of most of the functions included.
有几个答案建议使用 Windows 上的 GetModuleFileName。这些答案有一些缺点,例如:
GetModuleFileName
函数可能会失败并返回 0。GetModuleFileName
可能会返回相对可执行文件名称而不是全名GetModuleFileName
可能会返回一个短路径,例如C:\GIT-RE~1\TEST_G~1\test.exe
让我提供一个改进版本,考虑了上述几点:
There are several answers recommending using GetModuleFileName on Windows. These answers have some shortcomings like:
GetModuleFileName
function may fail and return 0.GetModuleFileName
may return a relative executable name instead of a full nameGetModuleFileName
may return a short path likeC:\GIT-RE~1\TEST_G~1\test.exe
Let me provide an improved version, which takes into account the abovementioned points:
正如其他人提到的,
argv[0]
是一个非常好的解决方案,前提是平台实际上传递了可执行文件路径,这肯定不比操作系统是 Windows 的可能性小(其中 WinAPI 可以帮助找到可执行文件)小路)。如果您想删除字符串以仅包含可执行文件所在目录的路径,那么使用该路径查找其他应用程序文件(例如游戏资产,如果您的程序是游戏)是完全可以的,因为打开文件是相对于工作目录,或者根目录(如果提供)。As others mentioned,
argv[0]
is quite a nice solution, provided that the platform actually passes the executable path, which is surely not less probable than the OS being Windows (where WinAPI can help find the executable path). If you want to strip the string to only include the path to the directory where the executable resides, then using that path to find other application files (like game assets if your program is a game) is perfectly fine, since opening files is relative to the working directory, or, if provided, the root.以下是一个快速但肮脏的解决方案,但请注意,它远非万无一失:
The following works as a quick and dirty solution, but note that it is far from being foolproof:
如果您需要处理 Windows 的 unicode 路径:
In case you need to handle unicode paths for Windows:
这是我的简单解决方案,适用于 Windows 和 Linux,基于 此解决方案 并使用 这个答案:
Here my simple solution that works in both Windows and Linux, based on this solution and modified with this answer:
对于 Windows,您会遇到如何从
GetModuleFileName()
结果中删除可执行文件的问题。 Nate 在其答案中为此目的使用的 Windows API 调用PathRemoveFileSpec()
在 Windows 8 及其前身之间发生了变化。那么如何保持两者兼容又安全呢?幸运的是,有 C++17(或者 Boost,如果您使用的是较旧的编译器)。我这样做:For Windows, you have the problem of how to strip the executable from the result of
GetModuleFileName()
. The Windows API callPathRemoveFileSpec()
that Nate used for that purpose in his answer changed between Windows 8 and its predecessors. So how to remain compatible with both and safe? Luckily, there's C++17 (or Boost, if you're using an older compiler). I do this:SDL2 (https://www.libsdl.org/) 库有两个函数在广泛的领域实现平台:
因此,如果您不想重新发明轮子...可悲的是,这意味着包括整个库,尽管它有一个相当宽松的许可证,并且也可以复制代码。此外,它还提供了许多其他跨平台功能。
SDL2 (https://www.libsdl.org/) library has two functions implemented across a wide spectrum of platforms:
So if you don't want to reinvent the wheel... sadly, it means including the entire library, although it's got a quite permissive license and one could also just copy the code. Besides, it provides a lot of other cross-platform functionality.
我没有阅读我的解决方案是否已发布,但在 Linux 和 osx 上,您可以在主函数中读取 0 参数,如下所示:
在 argument_list 的第一项中,可执行文件的名称已集成,但被上面的代码删除。
I didn't read if my solution is already posted but on linux and osx you can read the 0 argument in your main function like this:
In the first item of argument_list the name of the executable is integrated but removed by the code above.
有一个专门用于此目的的 C 库:whereami.c。
支持的平台:
There's a C library dedicated to this: whereami.c.
Supported platforms:
这是我在 Windows 中的解决方案。它的名称如下:
其中 64 是您认为路径的最小大小。 GetPathOfEXE 递归地调用自身,每次将缓冲区的大小加倍,直到获得足够大的缓冲区以获取整个路径而不被截断。
This was my solution in Windows. It is called like this:
Where 64 is the minimum size you think the path will be. GetPathOfEXE calls itself recursively, doubling the size of the buffer each time until it gets a big enough buffer to get the whole path without truncation.
在 Unix(包括 Linux)中尝试“which”,在 Windows 中尝试“where”。
in Unix(including Linux) try 'which', in Windows try 'where'.
从 C++17 开始:
确保包含 std 文件系统。
现在你可以做到这一点。
boost 文件系统成为标准库的一部分。
如果您找不到它,请尝试查看以下内容:
As of C++17:
Make sure you include std filesystem.
and now you can do this.
boost filesystem became part of the standard lib.
if you can't find it try to look under: