This question already has answers here:
Finding current executable's path without /proc/self/exe
(14 answers)
Closed 7 years ago.
Is there a way in C/C++ to find the location (full path) of the current executed program?
(The problem with argv[0] is that it does not give the full path.)
To summarize:
On Unixes with /proc really straight and realiable way is to:
readlink("/proc/self/exe", buf, bufsize) (Linux)
readlink("/proc/curproc/file", buf, bufsize) (FreeBSD)
readlink("/proc/self/path/a.out", buf, bufsize) (Solaris)
On Unixes without /proc (i.e. if above fails):
If argv[0] starts with "/" (absolute path) this is the path.
Otherwise if argv[0] contains "/" (relative path) append it to cwd
(assuming it hasn't been changed yet).
Otherwise search directories in $PATH for executable argv[0].
Afterwards it may be reasonable to check whether the executable isn't actually a symlink.
If it is resolve it relative to the symlink directory.
This step is not necessary in /proc method (at least for Linux).
There the proc symlink points directly to executable.
Note that it is up to the calling process to set argv[0] correctly.
It is right most of the times however there are occasions when the calling process cannot be trusted (ex. setuid executable).
On Windows: use GetModuleFileName(NULL, buf, bufsize)
Use GetModuleFileName() function if you are using Windows.
Please note that the following comments are unix-only.
The pedantic answer to this question is that there is no general way to answer this question correctly in all cases. As you've discovered, argv[0] can be set to anything at all by the parent process, and so need have no relation whatsoever to the actual name of the program or its location in the file system.
However, the following heuristic often works:
If argv[0] is an absolute path, assume this is the full path to the executable.
If argv[0] is a relative path, ie, it contains a /, determine the current working directory with getcwd() and then append argv[0] to it.
If argv[0] is a plain word, search $PATH looking for argv[0], and append argv[0] to whatever directory you find it in.
Note that all of these can be circumvented by the process which invoked the program in question. Finally, you can use linux-specific techniques, such as mentioned by emg-2. There are probably equivalent techniques on other operating systems.
Even supposing that the steps above give you a valid path name, you still might not have the path name you actually want (since I suspect that what you actually want to do is find a configuration file somewhere). The presence of hard links means that you can have the following situation:
-- 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
Now, the approach above (including, I suspect, /proc/$pid/exe) will give /some/where/else/foo as the real path to the program. And, in fact, it is a real path to the program, just not the one you wanted. Note that this problem doesn't occur with symbolic links which are much more common in practice than hard links.
In spite of the fact that this approach is in principle unreliable, it works well enough in practice for most purposes.
Not an answer actually, but just a note to keep in mind.
As we could see, the problem of finding the location of running executable is quite tricky and platform-specific in Linux and Unix. One should think twice before doing that.
If you need your executable location for discovering some configuration or resource files, maybe you should follow the Unix way of placing files in the system: put configs to /etc or /usr/local/etc or in current user home directory, and /usr/share is a good place to put your resource files.
In many POSIX systems you could check a simlink located under /proc/PID/exe. Few examples:
# file /proc/*/exe
/proc/1001/exe: symbolic link to /usr/bin/distccd
/proc/1023/exe: symbolic link to /usr/sbin/sendmail.sendmail
/proc/1043/exe: symbolic link to /usr/sbin/crond
Remember that on Unix systems the binary may have been removed since it was started. It's perfectly legal and safe on Unix. Last I checked Windows will not allow you to remove a running binary.
/proc/self/exe will still be readable, but it will not be a working symlink really. It will be... odd.
On Mac OS X, use _NSGetExecutablePath.
See man 3 dyld and this answer to a similar question.
For Linux you can find the /proc/self/exe way of doing things bundled up in a nice library called binreloc, you can find the library at:
http://autopackage.org/docs/binreloc/
I would
1) Use the basename() function: http://linux.die.net/man/3/basename
2) chdir() to that directory
3) Use getpwd() to get the current directory
That way you'll get the directory in a neat, full form, instead of ./ or ../bin/.
Maybe you'll want to save and restore the current directory, if that is important for your program.
Related
Hey, I've been writing a program (a sort of e-Book viewing type thing) and it loads text files from a folder within the folder of which the executable is located. This gives me a bit of a problem since if I run the program from another directory with the command "./folder/folder/program" for example, my program will not find the text, because the working directory isn't correct. I cannot have an absolute directory because I would like the program to be portable. Is there any way to get the precise directory that the executable is running from even if it has been run from a different directory. I've heard could combine argc[0] and getcwd() but argc is truncated when there is a space in the directory, (I think?) so I would like to avoid that if possible.
I'm on Linux using g++, Thanx in advance
EDIT - don't use getcwd(), it's just where the user is not where the executable is.
See here for details.
On linux /proc/<pid>/exe or /proc/self/exe should be a symbolic link to your executable. Like others, I think the more important question is "why do you need this?" It's not really UNIX form to use the executable path to find ancillary files. Instead you use an environment variable or a default location, or follow one of the other conventions for finding the location of ancillary files (ie, ~/.<myapp>rc).
When you add a book to your library you can remember its absolute path.
It is not a bad when your program rely on the fact that it will be launched from the working dir and not from some other dir. That's why there are all kinds of "links" with "working dir" parameter.
You don't have to handle such situations in the way you want. Just check if all necessary files and dirs structure are in place and log an error with the instructions if they are not.
Or every time when your program starts and doesn't find necessary files the program can ask to point the path to the Books Library.
I still don't see the reason to know your current dir name.
#include <boost/filesystem/convenience.hpp>
#include <iostream>
#include <ostream>
int main(int argc, char** argv)
{
boost::filesystem::path argvPath( argv[0] );
boost::filesystem::path executablePath( argvPath.parent_path() );
boost::filesystem::path runPath( boost::filesystem::initial_path() );
std::cout << executablePath << std::endl;
std::cout << runPath << std::endl;
return 0;
}
You can get the path of the running program by reading the command line. In linux you can get the command line by reading /proc folder as /proc/PID/CommandLine
argv[0] is not truncated when there are spaces. However, it will only have the program name and not the path when a program is run from a directory listed in the PATH environment variable.
In any case, what you are trying to do here is not good design for a Unix/Linux program. Data files are not stored in the same directory as program files because doing so makes it difficult to apply proper security policies.
The best way to get what you want in my opinion is to use a shell script to launch the actual program. This is very similar to how Firefox launches on Linux systems. The shell places the name of the script into $0 and this variable will always have a path. Then you can use an environment variable or command line argument to give your program the location of the data files, like this:
dir=`dirname "$0"`
cd "$dir/../data/"
"$dir/real-program"
And I would arrange your program so that it's files are somewhat like this:
install-dir/bin/program
install-dir/bin/real-program
install-dir/etc/config
install-dir/data/book-file.mobi
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What should Linux/Unix 'make install' consist of?
I'm making a program that can be invoked from the command line, like ./prog arg1 arg2. I was wondering, how can I make it so that I can run it from anywhere on the system? I know that I could put prog into /usr/bin/, but what if my program needs resources from its install directory (that can be wherever the user downloaded it)?
put the directory in which your program resides into the path environment variable or move your program into one of the directories already in path (usually requires superuser permission, which I gather you don't have for then you wouldn't ask this question).
to add a directory to the front of the search path and have the system refresh its database on tcsh, say
setenv "my/directory:"$PATH
rehash
on bash, I think, it's
PATH=/my/directory:$PATH
export PATH
(no need to rehash). Note that the above commands put your directory at the top of the search path, i.e. these will be searched before any other. Thus, if your program is called "gcc", then your program will be executed rather than the GNU C compiler. Alternatively, you can add your directory to the end of the search path, in which case your program will only be picked up if no other program of the same name is found in any of the other directories in the search path.
You probably also want to become familiar with the Linux Filesystem Hierarchy: the standard definition for "what goes where". Here's more information:
https://superuser.com/questions/90479/what-is-the-conventional-install-location-for-applications-in-linux
Environment variables can be defined globally ("for everybody", e.g. /etc/profile), or locally ("per user", e.g. ~/.bashrc). Here's a good summary of some of your options:
https://wiki.archlinux.org/index.php/Environment_Variables
When you execute a programme using prog arg1 arg2, it's thanks to your shell, which search in the $PATH environement variable for folders where programs are. (Try env | grep PATH to see those folder).
You need eather to add a new directory in this variable (export PATH="/new/directory/path/:$PATH" if under bash, setenv PATH "/new/directory/path/:$PATH" if with tcsh) or copy your program and all the files it need to execute in one of the PATH folder.
There are two ways of dealing with this (and Makefiles have nothing to do with them)
Your installer could just put the files where it wants them, so your program doesn't have to search -- it can use hardcoded paths. Or you could put the path to the data directory into yet another file, which would be hardcoded (like /etc/programname.config).
You put all your stuff into one directory (often something like /opt/programname). You can hardcode that too, of course, or your program can readlink() the /proc/pid/exe file for a good chance (no guarantee, though. In particular, it works if for example a symlink is used to point from /usr/bin/programname to your /opt/programname/bin/programname or whatever, but it won't work if that's a hardlink)
to get the path to the executable. From there you should be able to reach your data files.
If prefer the second solution, but that's just me. The first solution works well with package managers, and it's less overkill if you don't really have a lot of data files.
I want to open a number of files (log4cxx configs, other logs etc) relative to binary's location.
Unfortunately, both getwd() and getcwd() are giving me the directory, from which I try to run binary at known path, instead of giving me the path where the binary is located (and where the data is).
How to get the app's path to use it with chdir()? Any methods besides argv[0] and without trying to parse /proc/$PID/ (that's not portable enough)?
Walk the PATH and find an executable of the same name as argv[0]?
However, it would probably be better to provide the user a way to configure where the data is. An env var or config file or CL parameter or something. It's very frustrating dealing with programs that try to be helpful but are actually just stupid.
This is exactly the kind of thing autoconf lives for, and supporting those standard directories is pretty much mandatory if you ever want anyone other than the programmers who wrote your software to use it. Once set up properly, to debug out of your home directory all you have to do is pass a different --prefix= value to configure.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
If you look at point (6) here: http://www2.warwick.ac.uk/fac/sci/moac/students/peter_cock/cygwin/part3/
Why should we type ./ before the .exe file in order for it to run?
Why cannot we type hello.exe immediately?
Thanks.
Usually because intelligent people don't have their current directory . on the path :-)
The path is an environment variable like /bin:/usr/bin:/usr/sbin, and it's a list of directories to look in for finding executables, such as when you type in hello.
Unlike Windows, many UNIX shells don't automatically search the current directory for an executable. They must be listed in the path otherwise they are not run.
That's because to do otherwise is actually an attack vector. For example, if you create an ls program in your home directory and tell one of the administrators that there's a funny file in there, they may go to your directory and enter ls to see what's in there.
For a silly administrator that has the current directory before the "real" location of ls, they are now compromised, because your code is running with their full privileges.
That's why they tend not to do that.
Some people (not I) will put . on their path to make their lives easier but, even then, they'll put it at the end so that other locations are searched first.
Administrators don't have the luxury of being that trusting.
Because the current working directory is not in the PATH?
Or at least, that's how things are setup on Unix-style systems, I assume CYGWIN does the same.
On Windows, the current directory is always in the search path for an executable. The search order is "look in the current dir, if not found, look in the directories listed in the PATH environment variable".
From MS site:
The operating system always searches
in the current directory first, before
it searches the directories in the
command path.
(which makes all the warning here of not putting the . in your PATH irrelevant, IMHO)
On Linux this is not the case (for current dir). So, to run an executable which is in your current dir you need to write ./exe_name.
As Cygwin, again AFAIK, is for Windows, the ./ is not needed and seems to be just a copy/paste or preserving the unix-style the writer is used to.
EDIT: this is the issue of the command processor (the shell) as pointed out in comments and as I explain below, so if you are using a Unix-like shell on Windows, you still may need this style.
EDIT: elaborating on .\
. (not ./ to be exact) is an alias to the current directory. On Unix, every newly created directory is not "born" empty but contains 2 children: ., which is a self-reference, and .. which is a reference to the parent directory. Both are just regular directories, as any other. You don't see them when you run the ls command (same as dir on Windows) because names starting with . are special in the sense that they are not displayed by default. However, you can see them by ls -a.
When you run a command at the prompt, if the command is only a (file) name, the system (actually, the shell) searches the PATH for the file with this name.
If the command contains a path (not necessarily an absolute path, e.g. subdir1/exe) the system looks for the executable where you specified. Hence, writing ./exe means file exe in the current dir.
Cygwin is a Unix-like runtime environment and as such follows the way paths are searched for executables in such environments. The default executable search path of Unices does not contain the current directory. Thus if one wants to run an executable not located in one of the directories set in PATH a full path must be given. ./ is a shorthand for the current directory, also called process working directory (pwd). Be advised that it's a very bad idea to have the pwd being included in the executable search path.
Cygwin follows the Unix limitations on executing files in the current working directory. In Unix style terminal environments an executable must have ./ prepended if it is to be executed from the current directory. This is because the current directory "." is not part of the PATH environmment in order to limit the damage done by malware. Cygwin is simply following this convention, it has nothing per say to do with C++ programs
That's just an issue with your 'path' or 'PATH' variable in your shell. (probably your shell is bash, so it'd be PATH.)
echo $PATH
A typical 'user' path to do what you want would start with "." as a path element. This is a minor security risk of course.
Hey, I've been writing a program (a sort of e-Book viewing type thing) and it loads text files from a folder within the folder of which the executable is located. This gives me a bit of a problem since if I run the program from another directory with the command "./folder/folder/program" for example, my program will not find the text, because the working directory isn't correct. I cannot have an absolute directory because I would like the program to be portable. Is there any way to get the precise directory that the executable is running from even if it has been run from a different directory. I've heard could combine argc[0] and getcwd() but argc is truncated when there is a space in the directory, (I think?) so I would like to avoid that if possible.
I'm on Linux using g++, Thanx in advance
EDIT - don't use getcwd(), it's just where the user is not where the executable is.
See here for details.
On linux /proc/<pid>/exe or /proc/self/exe should be a symbolic link to your executable. Like others, I think the more important question is "why do you need this?" It's not really UNIX form to use the executable path to find ancillary files. Instead you use an environment variable or a default location, or follow one of the other conventions for finding the location of ancillary files (ie, ~/.<myapp>rc).
When you add a book to your library you can remember its absolute path.
It is not a bad when your program rely on the fact that it will be launched from the working dir and not from some other dir. That's why there are all kinds of "links" with "working dir" parameter.
You don't have to handle such situations in the way you want. Just check if all necessary files and dirs structure are in place and log an error with the instructions if they are not.
Or every time when your program starts and doesn't find necessary files the program can ask to point the path to the Books Library.
I still don't see the reason to know your current dir name.
#include <boost/filesystem/convenience.hpp>
#include <iostream>
#include <ostream>
int main(int argc, char** argv)
{
boost::filesystem::path argvPath( argv[0] );
boost::filesystem::path executablePath( argvPath.parent_path() );
boost::filesystem::path runPath( boost::filesystem::initial_path() );
std::cout << executablePath << std::endl;
std::cout << runPath << std::endl;
return 0;
}
You can get the path of the running program by reading the command line. In linux you can get the command line by reading /proc folder as /proc/PID/CommandLine
argv[0] is not truncated when there are spaces. However, it will only have the program name and not the path when a program is run from a directory listed in the PATH environment variable.
In any case, what you are trying to do here is not good design for a Unix/Linux program. Data files are not stored in the same directory as program files because doing so makes it difficult to apply proper security policies.
The best way to get what you want in my opinion is to use a shell script to launch the actual program. This is very similar to how Firefox launches on Linux systems. The shell places the name of the script into $0 and this variable will always have a path. Then you can use an environment variable or command line argument to give your program the location of the data files, like this:
dir=`dirname "$0"`
cd "$dir/../data/"
"$dir/real-program"
And I would arrange your program so that it's files are somewhat like this:
install-dir/bin/program
install-dir/bin/real-program
install-dir/etc/config
install-dir/data/book-file.mobi