How to get full path to process?
Todd Osborne
FAQ's. I need to be able to get the fully qualified path to my running
process, in C. argv[0] doesn't work, since it does not normally contain the
full path to the process, and I cannot find any other method to get this
information. Surely there is a good solution to this problem, and I would
greatly appreciate a pointer to it. Under Win32, GetModuleFileName(NULL)
does it. Is there a similar function in Linux? Is there a portable solution
between Linux and the other UNIX's out there? Thanks,
Peter T. Breuer
: I have seen this question asked and unanswered many times, even on the C/C++
: FAQ's. I need to be able to get the fully qualified path to my running
It is a FAQ, and as I recall, answered in the FAQs!
: process, in C. argv[0] doesn't work, since it does not normally contain the
: full path to the process, and I cannot find any other method to get this
Obviously you just look at argv[0], do a getenv("PATH"), then possibly
search through the components until you get a match.
: information. Surely there is a good solution to this problem, and I would
: greatly appreciate a pointer to it. Under Win32, GetModuleFileName(NULL)
system("which FOO"), perhaps?
: does it. Is there a similar function in Linux? Is there a portable solution
You can also open your dir in /proc and look. Never used that myself.
: between Linux and the other UNIX's out there? Thanks,
Peter
phil-new...@ipal.net
| I have seen this question asked and unanswered many times, even on the C/C++
| FAQ's. I need to be able to get the fully qualified path to my running
| process, in C. argv[0] doesn't work, since it does not normally contain the
| full path to the process, and I cannot find any other method to get this
| information. Surely there is a good solution to this problem, and I would
| greatly appreciate a pointer to it. Under Win32, GetModuleFileName(NULL)
| does it. Is there a similar function in Linux? Is there a portable solution
| between Linux and the other UNIX's out there? Thanks,
That information may not exist. The executeable may have been referenced
by a relative name rather than an absolute path. The executed inode may
not tell you much as it may have no longer have a link, or it may have more
than one.
Under Win32, the filesystem works differently. In most UNIX systems, the
filesystem is a flat array of numerically referenced files, with a named
hierarchy of directories that point to these numbers. Duplications and
even missing references are all valid conditions. Once a file is open,
the only information the kernel needs to keep is the inode (its number
and contents) and related structural information (block pointers). The
name of the file isn't needed, and isn't guaranteed to even be of any use.
What you do is get the inode number (and device number for which filesystem
it is on since each filesystem has its own set of inode numbers). Then you
search through all the directories in that filesystem for any references to
the inode in question. Don't stop at the first one unless a single arbitrary
one will suit your needs; there may be more matches. There is a reference
count you can use to know when you have found them all. See the man pages
for readdir and stat and go from there.
--
| Phil Howard - KA9WGN | for headlines that | Just say no to absurd patents |
| phil-...@ipal.net | really matter: | Boycott Amazon.Com (AMZN) |
| Dallas - Texas - USA | linuxhomepage.com | Shop http://bn.com/ instead |
Lew Pitcher
Osborne" <to...@toddtown.com> wrote:
>I have seen this question asked and unanswered many times, even on the C/C++
>FAQ's. I need to be able to get the fully qualified path to my running
>process, in C. argv[0] doesn't work, since it does not normally contain the
>full path to the process, and I cannot find any other method to get this
>information. Surely there is a good solution to this problem, and I would
>greatly appreciate a pointer to it. Under Win32, GetModuleFileName(NULL)
>does it. Is there a similar function in Linux? Is there a portable solution
>between Linux and the other UNIX's out there? Thanks,
AFAIK there is no way to get a definitive full path of an executing process in
Linux or any other Unix for that matter. Consider the following sequence of
shell commands:
mkdir /workdir
mkdir /workdir/subdir
cc -o /workdir/subdir/pgm pgm.c
chmod a+x /workdir/subdir/pgm
ln /workdir/subdir/pgm /workdir/newpgm
/workdir/newpgm
At this point, there is an executing process which was launched with the
full path name of /workdir/newpgm. However, this file _also_ has the name
/workdir/subdir/pgm. Which name should a (hypothetical) Linux
GetModuleFileName(NULL) return? Both names are valid, and the name that the
binary was given when created is still valid, _and_ different from the one that
was used to start the binary.
In this case, you could use argv[0], but argv[0] wouldn't reflect the entire
path name if I had instead started the program by using
cd /workdir
./newpgm
or even invoked it from another binary using
{
chdir("/workdir");
execl("newpgm","you will never guess",NULL);
}
In general, there's no way to get an authorative answer to "what exact path am I
executing from?".
Additionally, you probably should examine your assumptions as to _why_ you want
or need the full path information. Likely, you _don't_ need it.
Finally, remember: MS Windows isn't the only OS paradigm around, nor is it the
_absolutely correct_ paradigm. Other operating environments have different ways
to do things, and if you spend time learning "the way to do it in xxx" rather
than trying to find "how xxx does this MSWindows thing", you'll not get as
frustrated, and you'll probably write better code. Think of it this way: it's
the "Ugly tourist" problem where a foreigner comes over and complains that the
place that he is visiting doesn't do things the 'right' way; the way _he_ is
used to. (Tourist: "These damn foreigners drive on the wrong side of the road!
Someone should make them drive on the _right_ side of the road, like I do!")
Good Luck...
Lew Pitcher
Master Codewright and JOAT-in-training
Todd Osborne
determine the program path, so that configuration file(s) etc are stored in
the same location. I know this is done differently under Unix, where the
config file paths are normally compiled into the code, or a link is created
from a known location. However, since this is porting, I need to make the
Unix stuff work like the Windows code. Thanks for you help.
Todd
"Lew Pitcher" <pit...@arvotek.net> wrote in message
news:384aa20f...@merlin.l6s4x6.freehold.ca...
Grant Edwards
>> FAQ's. I need to be able to get the fully qualified path to my running
>> process,
Short answer: you can't. At least not in a way that is
guaranteed to work all of the time, and even then it's not
trivial.
More cryptic short answer: Files don't have names/paths in
Unix, they have i-node numbers. In OOP-speak: A filename isn't
not a property of a file, it is a property of a directory
entry.
Perhaps a better tack would be to describe the problem you are
trying to solve and somebody can tell you how that is usually
handled in Unix?
>> in C. argv[0] doesn't work, since it does not normally contain the
>> full path to the process, and I cannot find any other method to get this
>> information. Surely there is a good solution to this problem, and I would
>> greatly appreciate a pointer to it. Under Win32, GetModuleFileName(NULL)
>> does it. Is there a similar function in Linux? Is there a portable solution
>> between Linux and the other UNIX's out there? Thanks,
>
>That information may not exist. The executeable may have been referenced
>by a relative name rather than an absolute path. The executed inode may
>not tell you much as it may have no longer have a link, or it may have more
>than one.
It may have been executed via one or more symbolic links also:
then which name do you want, the name of the symbolic link that
was used in the exec() system call, or the contents of the last
symbolic link?
You can use the "find" program to list the pathnames of all of
hard links to a particular i-node, or you can do it yourself
using the method described in the stuff I deleted from the
previous response.
Not the answer you wanted to hear...
--
Grant Edwards grante Yow! Yow! Are we laid
at back yet?
visi.com
Grant Edwards
>I am porting a class library to Linux. One of the functions needs to
>determine the program path, so that configuration file(s) etc are stored in
>the same location.
Storing writable data (configuration) in the same place as
read-only stuff (executables), is evil, Evil, EVIL. (For a
handful of reasons we won't go into.) I know, that's how
MS-Windows does it, so you're stuck with it...
This is often handled on Unix systems by searching the
directories listed in the PATH environment variable for the
files in question. If the user doesn't want config files in
his PATH (who would?), then one usually sets an environment
variable to tell the app where to look.
--
Grant Edwards grante Yow! Do you need
at any MOUTH-TO-MOUTH
visi.com resuscitation?
Diophantus
>In article <lxN24.324$Jp2....@typhoon.southeast.rr.com>, Todd Osborne wrote:
>
>>I am porting a class library to Linux. One of the functions needs to
>>determine the program path, so that configuration file(s) etc are stored in
>>the same location.
>
>Storing writable data (configuration) in the same place as
>read-only stuff (executables), is evil, Evil, EVIL. (For a
>handful of reasons we won't go into.) I know, that's how
>MS-Windows does it, so you're stuck with it...
Actually how MS-Windows does it is via the registry. Only badly written Windows
programs (to the extent that this doesn't imply there are well written windows
programs) store their configuration information along with the executable. The
registry is still clumsy, but it's a step better.
Arthur Gold
>
> I have seen this question asked and unanswered many times, even on the C/C++
> FAQ's. I need to be able to get the fully qualified path to my running
> full path to the process, and I cannot find any other method to get this
> information. Surely there is a good solution to this problem, and I would
> greatly appreciate a pointer to it. Under Win32, GetModuleFileName(NULL)
> does it. Is there a similar function in Linux? Is there a portable solution
> between Linux and the other UNIX's out there? Thanks,
>
> to...@toddtown.com
If you're running a 2.2 kernel, you _might_ get just the information you
need from the /proc filesystem.
If you look at the file /proc/self/maps, you'll see the mappings for the
process...and at the far right of the first line the path of the
executable should appear.
For example, here is the output of `less /proc/self/maps`:
08048000-0805a000 r-xp 00000000 16:41 351685 /usr/bin/less
0805a000-0805c000 rw-p 00011000 16:41 351685 /usr/bin/less
0805c000-0805f000 rwxp 00000000 00:00 0
40000000-4000b000 r-xp 00000000 03:01 69372 /lib/ld-2.0.7.so
4000b000-4000c000 rw-p 0000a000 03:01 69372 /lib/ld-2.0.7.so
4000c000-4000d000 rwxp 00000000 00:00 0
40017000-4004d000 r-xp 00000000 03:01 69371 /lib/libncurses.so.4.2
4004d000-40057000 rw-p 00035000 03:01 69371 /lib/libncurses.so.4.2
40057000-4005b000 rw-p 00000000 00:00 0
4005b000-400f5000 r-xp 00000000 03:01 69392 /lib/libc.so.6
400f5000-400fc000 rw-p 00099000 03:01 69392 /lib/libc.so.6
400fc000-40108000 rw-p 00000000 00:00 0
bfffc000-c0000000 rwxp ffffd000 00:00 0
('self' refers to the running process, in this case, 'less')
HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
mailto:ag...@bga.com or mailto:ag...@cs.utexas.edu
--
?
Rick Walker
: >read-only stuff (executables), is evil, Evil, EVIL. (For a
: >handful of reasons we won't go into.) I know, that's how
: >MS-Windows does it, so you're stuck with it...
Even worse, UNIX is a multi-user OS. The config file should be
user-specific, and should reside in the *users* home directory - not
in a system-wide file.
The common paradigm is to keep the information is a file called
"~/.<progname>.rc". "~" of course, is an abbreviation for the
home directory of the current user. The initial "." in the name
makes the file normally invisible.
Best regards,
--
Rick Walker
Simon Williams
news:slrn84o0h...@grante.comtrol.com...
> In article <lxN24.324$Jp2....@typhoon.southeast.rr.com>, Todd
Osborne wrote:
>
> >I am porting a class library to Linux. One of the functions needs to
> >determine the program path, so that configuration file(s) etc are
stored in
> >the same location.
>
> read-only stuff (executables), is evil, Evil, EVIL. (For a
> handful of reasons we won't go into.) I know, that's how
> MS-Windows does it, so you're stuck with it...
>
> directories listed in the PATH environment variable for the
> files in question. If the user doesn't want config files in
> his PATH (who would?), then one usually sets an environment
> variable to tell the app where to look.
>
stuff with the executables and the Unix version stored the stuff in /etc
(or /usr/etc, etc.). I cannot see that it would really affect the
program that much. If you are trying to use a single piece of source
for all platforms, you are going to need to put some platform dependant
conditional compilation stuff in their anyway.
I would suggest that you put a GetConfigFileName or OpenConfigFile
function or similar into your library which could be different for
different platforms. In fact, thinking about it, the configuration file
should have its own class encapsulating it, in which case the rest of
the system does not care where it is or how to find it.
--
+------------------------------+--------------------------------------+
| Simon Williams | Opinions expressed here are not |
| si...@speedabv.demon.co.uk | necessarily those I held |
+------------------------------+ yesterday or those I will hold |
| Powered by Red Hat Linux 6.1 | tomorrow. Conisstency is boring. |
+------------------------------+--------------------------------------+
Stefaan A Eeckels
"Todd Osborne" <to...@toddtown.com> writes:
> I am porting a class library to Linux. One of the functions needs to
> determine the program path, so that configuration file(s) etc are stored in
> config file paths are normally compiled into the code, or a link is created
> from a known location. However, since this is porting, I need to make the
> Unix stuff work like the Windows code. Thanks for you help.
usually hasn't got write privileges for the file system that
holds the program. System-wide programs are usually stored in
/usr/local/bin, or /opt/bin, or suchlike, and -guess what-
J. Average User has only read/execute rights on these directories.
In any case, porting is more than making the app duplicate Windows
behaviour. It will be particularly useless if it doesn't run.
As a rule, user-specific configuration information is stored in
the user's home directory (a much more pervasive concept in UNIX
than in Windows), in a hidden file (.program.rc) or a hidden
directory. X based programs have compiled in defaults, but also
allow system-wide configuration files (in /home-of-X/lib/X11/app-defaults),
and user-specific configuration elements (in ~/.Xresources or
~/.Xdefaults). Coming from Windows, your program is likely to use
X, and that's the way it should be configured.
As I said, porting is more than slavishly copying behaviour
from one OS to another, especially if it doesn't make sense
on the target platform.
Take care,
--
Stefaan
--
--PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)--
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.
Christoph Hintermüller
> I have seen this question asked and unanswered many times, even on the C/C++
> FAQ's. I need to be able to get the fully qualified path to my running
> process, in C. argv[0] doesn't work, since it does not normally contain the
> full path to the process, and I cannot find any other method to get this
> information. Surely there is a good solution to this problem, and I would
> greatly appreciate a pointer to it. Under Win32, GetModuleFileName(NULL)
> does it. Is there a similar function in Linux? Is there a portable solution
> between Linux and the other UNIX's out there? Thanks,
>
> Todd
> to...@toddtown.com
Hi
Im not quite on Linux programming. But isn't there a possibility to access the
environment of the calling shell within a programm?? Then the programm could
reconstruct its absolut path from the PWD environment variable and path
fragments found in argv[0]. !!I do not mean opening a shell within the program
and checking the pwd!!
cu
Christopher
Joe Pfeiffer
> I am porting a class library to Linux. One of the functions needs to
> determine the program path, so that configuration file(s) etc are stored in
> the same location. I know this is done differently under Unix, where the
> config file paths are normally compiled into the code, or a link is created
> from a known location. However, since this is porting, I need to make the
> Unix stuff work like the Windows code. Thanks for you help.
It can't, in general, be done. It is the nature of the file system
that there is no guarantee that there only be a single path to a file,
so there may not be a unique program path.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Villy Kruse
Christoph Hintermüller <hin...@sbox.tu-graz.ac.at> wrote:
>Hi
>Im not quite on Linux programming. But isn't there a possibility to access the
>environment of the calling shell within a programm?? Then the programm could
>reconstruct its absolut path from the PWD environment variable and path
>fragments found in argv[0]. !!I do not mean opening a shell within the program
>and checking the pwd!!
- PWD might not be set if you are using a real strange shell.
- There is a standard procedure you can call from c which will give you
the current working directory so the PWD environment varible won't be
needed. It is called getcwd()
- It is not considered a good thing to run programs from current directory,
but rather from one of the directories in the PATH variable.
- Programs not started by shell might be given a argv[0] which has nothing
whatsoever to do with the path name of the program file. The execve()
system call which launches your process allows you to specify any value
for argv[0].
Villy
Todd Osborne
a reason NOT to use this function? The only time I can see that it would
fail is if argv[0] is NULL or empty. I have played with it just a little in
testing and found it to return the full program path 100% of the time as
long as argv[0] has a valid name.
Todd
"Todd Osborne" <to...@toddtown.com> wrote in message
news:vw224.282$En6....@typhoon.southeast.rr.com...
David Schwartz
>
> : >Storing writable data (configuration) in the same place as
> : >read-only stuff (executables), is evil, Evil, EVIL. (For a
> : >handful of reasons we won't go into.) I know, that's how
> : >MS-Windows does it, so you're stuck with it...
>
> user-specific, and should reside in the *users* home directory - not
> in a system-wide file.
The registry consists of several files. Some of them are
system-specific and hold system-specific data. Some of them are
user-specific and hold user-specific data. The registry database that
holds user-specific data is part of the user's profile and resides
wherever the user's profile data is stored -- this is somewhat analogous
to a home directory.
DS
Stefaan A Eeckels
David Schwartz <dav...@webmaster.com> writes:
>
> The registry consists of several files. Some of them are
> system-specific and hold system-specific data. Some of them are
> user-specific and hold user-specific data. The registry database that
> holds user-specific data is part of the user's profile and resides
> wherever the user's profile data is stored -- this is somewhat analogous
> to a home directory.
(like check the user data, then the system data, etc), and the
old GetProfile / GetPrivateProfile API dichotomy devolves that
responsibility to the application.
Thus, an ill-written application (ie one that targets the main
OS purporting to support Win32, Windows9x) would not be usable
by more than one user on Windows NT.
It would be nice if Windows had taken a leaf from X's book, and
included a genuine multi-user resource / configuration facility
(not that X's implementation of the idea is that hot, but it sure
is flexible :-).
David Schwartz
>
> In article <385F5F04...@webmaster.com>,
> David Schwartz <dav...@webmaster.com> writes:
> >
> > The registry consists of several files. Some of them are
> > system-specific and hold system-specific data. Some of them are
> > user-specific and hold user-specific data. The registry database that
> > holds user-specific data is part of the user's profile and resides
> > wherever the user's profile data is stored -- this is somewhat analogous
> > to a home directory.
> But if I'm not mistaken, there is no built-in search hierachy
> (like check the user data, then the system data, etc), and the
> old GetProfile / GetPrivateProfile API dichotomy devolves that
> responsibility to the application.
No, but as a partial defense of this design, that's not always the
right thing to do. Some system settings shouldn't necessarily by
overridable by the user.
> Thus, an ill-written application (ie one that targets the main
> OS purporting to support Win32, Windows9x) would not be usable
> by more than one user on Windows NT.
Yep. But Windows NT isn't 'really' meant to be a multi-user OS in that
sense.
> It would be nice if Windows had taken a leaf from X's book, and
> included a genuine multi-user resource / configuration facility
> (not that X's implementation of the idea is that hot, but it sure
> is flexible :-).
I have a love-hate relationship with the Windows registry concept. The
great thing about it is that all the configuration information is in one
place. The worst thing about it is that all the configuration
information is in one place.
DS
bosco
I'm affraid, my english isn't very good. But since I have not seen a
satisfactory answer in all this discussion, I give you a little code
sample which make exactly what you want. I extracted this code from an
existing application. Initialy the code integrated conditional
operators for Windows and VMS compilation. For clarity reasons, I
removed all this noise.
So, the given program investigates both the argv[0] and PATH
environment variable in order to retrieve the currently executed file
path and name.
The sympbolics links are parsed with the "realpath" standard subroutine.
Only the i-nodes links are not parsed because in this case the two file
names an paths are absolutly equivalent.
Here is the code (tested on AIX) (perhaps some #include are useless):
#define _POSIX_SOURCE
#define _XOPEN_SOURCE
#include <stdio.h>
#include <ctype.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#define FILENAME_BUF_SIZE 1024
static char program_home[FILENAME_BUF_SIZE];
static char program_name[FILENAME_BUF_SIZE];
static int my_faccess(
char *path,
int mode
)
{
struct stat stat_buf;
if ((stat(path, &stat_buf) != 0) || ((stat_buf.st_mode & S_IFMT) !=
S_IFREG))
return(-1);
if (mode)
return(access(path, mode));
return(0);
}
/*
* Set the 2 global variables "program_home" and "program_name"
* with respectively the directory and the name of the currently
executd file
* The symbolic link are parsed.
*/
static void setProgramHomeAndName(
char *cwd,
char *arg0
)
{
int i, j, lg;
char *path;
char buf[FILENAME_BUF_SIZE];
buf[0] = 0;
if ((strchr(arg0, '/') == 0) && (path = getenv("PATH"))) {
for (i = 0; path[i]; ) {
for (j = i; (path[j]) && (path[j] != ':'); j++);
lg = j - i;
strncpy(buf, path + i, lg);
if (lg == 0) buf[lg++] = '.';
buf[lg++] = '/';
strcpy(buf + lg, arg0);
if (my_faccess(buf, 01) == 0) break;
buf[0] = 0;
i = j;
if (path[i] == ':') i += 1;
}
}
if (buf[0] == 0) strcpy(buf, arg0);
if (realpath(buf, program_home) == NULL) {
if (buf[0] != '/') sprintf(program_home, "%s/%s", cwd, buf);
else strcpy(program_home, buf);
}
lg = strlen(program_home);
for (; (lg > 0) && (program_home[lg-1] != '/'); lg -= 1);
strcpy(program_name, program_home + lg);
program_home[lg] = 0;
printf("home=\"%s\"\n",program_home);
printf("name=\"%s\"\n",program_name);
}
main(argc, argv)
int argc;
char **argv;
{
char cwd[FILENAME_BUF_SIZE];
if (getcwd(cwd, FILENAME_BUF_SIZE) == 0)
fprintf(stderr, "Can't get working directory");
setProgramHomeAndName(cwd, argv[0]);
}
Best regards and good luck
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Stefaan A Eeckels
Tom Dorgan
specialized tool.
David Schwartz <dav...@webmaster.com> wrote in message
news:38606800...@webmaster.com...
> Stefaan A Eeckels wrote:
> >
> > In article <385F5F04...@webmaster.com>,
> > David Schwartz <dav...@webmaster.com> writes:
> > >
> > > The registry consists of several files. Some of them are
> > > system-specific and hold system-specific data. Some of them are
> > > user-specific and hold user-specific data. The registry database that
> > > holds user-specific data is part of the user's profile and resides
> > > wherever the user's profile data is stored -- this is somewhat
analogous
> > > to a home directory.
>
> > But if I'm not mistaken, there is no built-in search hierachy
> > (like check the user data, then the system data, etc), and the
> > old GetProfile / GetPrivateProfile API dichotomy devolves that
> > responsibility to the application.
>
> No, but as a partial defense of this design, that's not always the
> right thing to do. Some system settings shouldn't necessarily by
> overridable by the user.
>
> > Thus, an ill-written application (ie one that targets the main
> > OS purporting to support Win32, Windows9x) would not be usable
> > by more than one user on Windows NT.
>
> Yep. But Windows NT isn't 'really' meant to be a multi-user OS in that
> sense.
>
> > It would be nice if Windows had taken a leaf from X's book, and
> > included a genuine multi-user resource / configuration facility
> > (not that X's implementation of the idea is that hot, but it sure
> > is flexible :-).
>
> I have a love-hate relationship with the Windows registry concept. The
> great thing about it is that all the configuration information is in one
> place. The worst thing about it is that all the configuration
> information is in one place.
>
> DS
David Schwartz
Tom Dorgan wrote:
>
> Well, in either case, its not in a format that you can hack without a
> specialized tool.
And it's incredibly slow. And it grows larger and larger over time with
no good way to recover dead space.
DS