Very Computer

by **Stephan Kuhage** » Thu, 18 Oct 2001 22:40:41

Hello.

I need to get the full path of an executable from inside the
program. I know, that I can just look into /proc/PID/exe, but I need a
method, that is a bit more portable between other unix-systems.

Any help will be appreciated!
Thanks
Stephan

--
/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\

| >>> ...destination anywhere, -\<, |
| >>> east or west, I don't care... (*)/(*) |
| WWW: http://www.tzi.de/~stk |
\____________________________________________________________/

PS: Ich widerspreche der Nutzung oder Uebermittlung meiner
Daten fuer Werbezwecke oder fuer die Markt- und Meinungsforschung

(28 Abs. 3 Bundesdatenschutzgesetz)

by **Lew Pitch** » Thu, 18 Oct 2001 22:50:05

Quote:>Hello.

>I need to get the full path of an executable from inside the
>program. I know, that I can just look into /proc/PID/exe, but I need a
>method, that is a bit more portable between other unix-systems.

There is no portable unix method of determining the full path of the
executable from inside the program.

See the Unix FAQ, question 1.14
http://www.faqs.org/faqs/unix-faq/programmer/faq/

Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employer's.)

by **Kasper Dupon** » Thu, 18 Oct 2001 23:23:39

> >Hello.

> >I need to get the full path of an executable from inside the
> >program. I know, that I can just look into /proc/PID/exe, but I need a
> >method, that is a bit more portable between other unix-systems.

> There is no portable unix method of determining the full path of the
> executable from inside the program.

The best we can come up with is to use argv[0]:
- If it starts with a / assume it is the full path.
- If it contains a / assume it is a path relative
to the current directory.
- If it contains no / search through the PATH
environment variable for an executable with at
matching name.

Just keep in mind that somebody might deliberately
want to fool your program to think something else.

--
Kasper Dupont

by **Grant Edwar** » Thu, 18 Oct 2001 23:58:22

>> >Hello.

>> >I need to get the full path of an executable from inside the
>> >program. I know, that I can just look into /proc/PID/exe, but I need a
>> >method, that is a bit more portable between other unix-systems.

>> There is no portable unix method of determining the full path of the
>> executable from inside the program.

> The best we can come up with is to use argv[0]:
> - If it starts with a / assume it is the full path.
> - If it contains a / assume it is a path relative
> to the current directory.
> - If it contains no / search through the PATH
> environment variable for an executable with at
> matching name.

> Just keep in mind that somebody might deliberately
> want to fool your program to think something else.

What you should do is ask yourself:

Q: Why do I want to know where the executable is?
A: Because I want to do X.

Once you have that answer, then the question is: "Since I
_dont'_ know where my executable is, how do Unix programs
usually do X?"

--
Grant Edwards grante Yow! There's a lot of BIG
at MONEY in MISERY if you have
visi.com an AGENT!!

by **Kasper Dupon** » Fri, 19 Oct 2001 00:20:55

> >> >Hello.

> >> >I need to get the full path of an executable from inside the
> >> >program. I know, that I can just look into /proc/PID/exe, but I need a
> >> >method, that is a bit more portable between other unix-systems.

> >> There is no portable unix method of determining the full path of the
> >> executable from inside the program.

> > The best we can come up with is to use argv[0]:
> > - If it starts with a / assume it is the full path.
> > - If it contains a / assume it is a path relative
> > to the current directory.
> > - If it contains no / search through the PATH
> > environment variable for an executable with at
> > matching name.

> > Just keep in mind that somebody might deliberately
> > want to fool your program to think something else.

> What you should do is ask yourself:

> Q: Why do I want to know where the executable is?
> A: Because I want to do X.

I once had a suid binary that I wanted to modify
it's own filepermtions. My conclusion was that
there was no secure way to do that.

--
Kasper Dupont

by **David Fo** » Fri, 19 Oct 2001 21:37:54

> >> >Hello.

> >> >I need to get the full path of an executable from inside the
> >> >program. I know, that I can just look into /proc/PID/exe, but I need a
> >> >method, that is a bit more portable between other unix-systems.

> >> There is no portable unix method of determining the full path of the
> >> executable from inside the program.

> > The best we can come up with is to use argv[0]:
> > - If it starts with a / assume it is the full path.
> > - If it contains a / assume it is a path relative
> > to the current directory.
> > - If it contains no / search through the PATH
> > environment variable for an executable with at
> > matching name.

> > Just keep in mind that somebody might deliberately
> > want to fool your program to think something else.

> What you should do is ask yourself:

> Q: Why do I want to know where the executable is?
> A: Because I want to do X.

> Once you have that answer, then the question is: "Since I
> _dont'_ know where my executable is, how do Unix programs
> usually do X?"

Often this is done so that you can then locate the configuration files
associated with a program by searching directories near the
executable. If the files are not around (because the program was
invoked via a symbolic link or something) it just complains that the
installation is incorrect and exits.

by **Lew Pitch** » Fri, 19 Oct 2001 21:54:25

>> >> >Hello.

>> >> >I need to get the full path of an executable from inside the
>> >> >program. I know, that I can just look into /proc/PID/exe, but I need a
>> >> >method, that is a bit more portable between other unix-systems.

>> >> There is no portable unix method of determining the full path of the
>> >> executable from inside the program.

>> > The best we can come up with is to use argv[0]:
>> > - If it starts with a / assume it is the full path.
>> > - If it contains a / assume it is a path relative
>> > to the current directory.
>> > - If it contains no / search through the PATH
>> > environment variable for an executable with at
>> > matching name.

>> > Just keep in mind that somebody might deliberately
>> > want to fool your program to think something else.

>> What you should do is ask yourself:

>> Q: Why do I want to know where the executable is?
>> A: Because I want to do X.

>> Once you have that answer, then the question is: "Since I
>> _dont'_ know where my executable is, how do Unix programs
>> usually do X?"

>Often this is done so that you can then locate the configuration files
>associated with a program by searching directories near the
>executable. If the files are not around (because the program was
>invoked via a symbolic link or something) it just complains that the
>installation is incorrect and exits.

To which point 1.14.1 of the Unix Programmer's FAQ
(http://www.faqs.org/faqs/unix-faq/programmer/faq/) that I refered to says
"1.14.1 So where do I put my configuration files then?
-----------------------------------------------------

The correct directory for this usually depends on the particular flavour of
Unix you're using; `/var/opt/PACKAGE', `/usr/local/lib', `/usr/local/etc',
or any of several other possibilities. User-specific configuration files
are usually hidden `dotfiles' under `$HOME' (e.g. `$HOME/.exrc').

..."

Lew Pitcher
IT Consultant, Development Services
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')

by **David Fo** » Sat, 20 Oct 2001 18:40:57

> >> What you should do is ask yourself:

> >> Q: Why do I want to know where the executable is?
> >> A: Because I want to do X.

> >> Once you have that answer, then the question is: "Since I
> >> _dont'_ know where my executable is, how do Unix programs
> >> usually do X?"

> >Often this is done so that you can then locate the configuration files
> >associated with a program by searching directories near the
> >executable. If the files are not around (because the program was
> >invoked via a symbolic link or something) it just complains that the
> >installation is incorrect and exits.

> To which point 1.14.1 of the Unix Programmer's FAQ
> (http://www.faqs.org/faqs/unix-faq/programmer/faq/) that I refered to says
> "1.14.1 So where do I put my configuration files then?
> -----------------------------------------------------

> The correct directory for this usually depends on the particular flavour of
> Unix you're using; `/var/opt/PACKAGE', `/usr/local/lib', `/usr/local/etc',
> or any of several other possibilities. User-specific configuration files
> are usually hidden `dotfiles' under `$HOME' (e.g. `$HOME/.exrc').

> ..."

The argument in the FAQ is pretty weak, basically boiling down to
"This is considered to be bad form." Well excuuuse me!

by **David Fo** » Sat, 20 Oct 2001 18:51:40

> > >> What you should do is ask yourself:

> > >> Q: Why do I want to know where the executable is?
> > >> A: Because I want to do X.

> > >> Once you have that answer, then the question is: "Since I
> > >> _dont'_ know where my executable is, how do Unix programs
> > >> usually do X?"

> > >Often this is done so that you can then locate the configuration files
> > >associated with a program by searching directories near the
> > >executable. If the files are not around (because the program was
> > >invoked via a symbolic link or something) it just complains that the
> > >installation is incorrect and exits.

> > To which point 1.14.1 of the Unix Programmer's FAQ
> > (http://www.faqs.org/faqs/unix-faq/programmer/faq/) that I refered to says
> > "1.14.1 So where do I put my configuration files then?
> > -----------------------------------------------------

> > The correct directory for this usually depends on the particular flavour of
> > Unix you're using; `/var/opt/PACKAGE', `/usr/local/lib', `/usr/local/etc',
> > or any of several other possibilities. User-specific configuration files
> > are usually hidden `dotfiles' under `$HOME' (e.g. `$HOME/.exrc').

> > ..."

> The argument in the FAQ is pretty weak, basically boiling down to
> "This is considered to be bad form." Well excuuuse me!

I might add that compiling fixed paths like "/usr/local/lib" into your
executable is far poorer form than locating the configuration files
using the perfectly adequate method of examining argv[0] and scanning
$PATH. What if you want to install multiple versions of a program?
What if you want to test a new version in your home directory? What
if you want users without root permission to be able to install and
use your software? So what if it won't work if someone tries to invoke
it via a symbolic link? The "approved" method will fail too if you
put the configuration files in the wrong place.

by **Grant Edwar** » Sat, 20 Oct 2001 22:57:09

>> What you should do is ask yourself:

>> Q: Why do I want to know where the executable is?
>> A: Because I want to do X.

>> Once you have that answer, then the question is: "Since I
>> _dont'_ know where my executable is, how do Unix programs
>> usually do X?"

> Often this is done so that you can then locate the configuration files
> associated with a program by searching directories near the
> executable. If the files are not around (because the program was
> invoked via a symbolic link or something) it just complains that the
> installation is incorrect and exits.

Mixing configuration files (R/W data) with program executables
(RO data) is generally considered a bad idea. MSWindows does
it a *lot*.

'nuff said?

The Unix philosophy: executables go one place (it can be
read-only, shared between systems, updated when new versions
come out etc.). Configuration data goes somewhere else
(writable, unique to system or user, conserved across updates).

--
Grant Edwards grante Yow! I'm ZIPPY!! Are we
at having FUN yet??
visi.com

by **Grant Edwar** » Sat, 20 Oct 2001 23:13:16

>> >> What you should do is ask yourself:

>> >> Q: Why do I want to know where the executable is?
>> >> A: Because I want to do X.

>> >> Once you have that answer, then the question is: "Since I
>> >> _dont'_ know where my executable is, how do Unix programs
>> >> usually do X?"

>> >Often this is done so that you can then locate the configuration files
>> >associated with a program by searching directories near the
>> >executable. If the files are not around (because the program was
>> >invoked via a symbolic link or something) it just complains that the
>> >installation is incorrect and exits.

>> To which point 1.14.1 of the Unix Programmer's FAQ
>> (http://www.faqs.org/faqs/unix-faq/programmer/faq/) that I refered to says
>> "1.14.1 So where do I put my configuration files then?
>> -----------------------------------------------------

>> The correct directory for this usually depends on the particular flavour of
>> Unix you're using; `/var/opt/PACKAGE', `/usr/local/lib', `/usr/local/etc',
>> or any of several other possibilities. User-specific configuration files
>> are usually hidden `dotfiles' under `$HOME' (e.g. `$HOME/.exrc').

>> ..."

> The argument in the FAQ is pretty weak, basically boiling down to
> "This is considered to be bad form." Well excuuuse me!

You're excused. Go ahead an do it if you want. It's possible
that Unix progrmmers over the past 30 years were all wrong, and
you're right.

It is considered bad form.

1) That means that if you do it that way, your program won't
work the way the rest of the system does. In the SW
engineering classes I took the definition of a bug is "when
a program doesn't do what a user reasonably expects it to
do." That was the only useful thing I learned in those
classes.

On a Unix system, a reasonable user will not exepct that
the location of configuration files depends on the location
of the executable. If your program does so, it is therefore
a bug. It will cause problems for users.

2) It's considered bad form for a _reason_ (several, actually):

a) It's a very useful thing to be able to put executable
stuff in a read-only filesystem and share it amongst
hosts. This precludes putting configuration data in the
same location, since it generally needs to be both
writable and host-specific.

b) Placing configuration files in a seperate location makes
it far easier to upgrade/reinstall the OS or program
without loosing the configuration data.

c) Putting all of the configuration files in known,
predicatable locations makes it easy to take a
"snapshot" of your system configuration without having
to save gigabytes of executable images that you don't
care about. IOW, you don't have to back up /usr/bin as
often (or at all, on some systems) compared with /etc or
the user home directories.

d) Historically, there's no reliable way to _find_ the
executable's path.

One could argue about whether d is the result or cause of a-c,
but at this point in the history of Unix it's a moot point.

--
Grant Edwards grante Yow! I know things about
at TROY DONAHUE that can't
visi.com even be PRINTED!!

by **David Fo** » Sun, 21 Oct 2001 00:31:01

> >> >> What you should do is ask yourself:

> >> >> Q: Why do I want to know where the executable is?
> >> >> A: Because I want to do X.

> >> >> Once you have that answer, then the question is: "Since I
> >> >> _dont'_ know where my executable is, how do Unix programs
> >> >> usually do X?"

> >> >Often this is done so that you can then locate the configuration files
> >> >associated with a program by searching directories near the
> >> >executable. If the files are not around (because the program was
> >> >invoked via a symbolic link or something) it just complains that the
> >> >installation is incorrect and exits.

> >> To which point 1.14.1 of the Unix Programmer's FAQ
> >> (http://www.faqs.org/faqs/unix-faq/programmer/faq/) that I refered to says
> >> "1.14.1 So where do I put my configuration files then?
> >> -----------------------------------------------------

> >> The correct directory for this usually depends on the particular flavour of
> >> Unix you're using; `/var/opt/PACKAGE', `/usr/local/lib', `/usr/local/etc',
> >> or any of several other possibilities. User-specific configuration files
> >> are usually hidden `dotfiles' under `$HOME' (e.g. `$HOME/.exrc').

> >> ..."

> > The argument in the FAQ is pretty weak, basically boiling down to
> > "This is considered to be bad form." Well excuuuse me!

> You're excused. Go ahead an do it if you want. It's possible
> that Unix progrmmers over the past 30 years were all wrong, and
> you're right.

Since I've been a Unix programmer for twenty five years they can't
*all* have been wrong, but...

Quote:> It is considered bad form.

> 1) That means that if you do it that way, your program won't
> work the way the rest of the system does. In the SW
> engineering classes I took the definition of a bug is "when
> a program doesn't do what a user reasonably expects it to
> do." That was the only useful thing I learned in those
> classes.

> On a Unix system, a reasonable user will not exepct that
> the location of configuration files depends on the location
> of the executable. If your program does so, it is therefore
> a bug. It will cause problems for users.

Reasonable users don't care about the location of the configuration
files. They have no expectation one way or another. They expect the
application to perform the task for which it was designed.

Quote:> 2) It's considered bad form for a _reason_ (several, actually):

> a) It's a very useful thing to be able to put executable
> stuff in a read-only filesystem and share it amongst
> hosts. This precludes putting configuration data in the
> same location, since it generally needs to be both
> writable and host-specific.

It does not preclude this at all, in general if the executable is
found in a directory such as <whatever>/usr/bin/foo the program can
look in <whatever>/var/lib/foo/ for configuration files. If
<whatever> happens to be the empty string the configuration files will
be found on the writable /var filesystem.

Quote:> b) Placing configuration files in a seperate location makes
> it far easier to upgrade/reinstall the OS or program
> without loosing the configuration data.

Per-user configuration data is a separate issue, and of course belongs
in the user's home directory. We're talking about system-wide
configuration files, such as those that appear in /etc - the files
that are installed or created when the program is installed, not while
it is running.

Quote:> c) Putting all of the configuration files in known,
> predicatable locations makes it easy to take a
> "snapshot" of your system configuration without having
> to save gigabytes of executable images that you don't
> care about. IOW, you don't have to back up /usr/bin as
> often (or at all, on some systems) compared with /etc or
> the user home directories.

The relative method doesn't preclude a program from installing its
configuration files in /etc, as demonstrated by my example above.
What it does do is allow multiple versions to coexist.

Quote:> d) Historically, there's no reliable way to _find_ the
> executable's path.

This is true in theory but irrelevant in practice. If the program's
installation is screwed up to the point that it can't find its own
executable you go in and fix it, like any other bug.

by **Robert Redelmeie** » Sun, 21 Oct 2001 01:10:11

[/bin vs /usr/package argument snipped]

Quote:> d) Historically, there's no reliable way to
> _find_ the executable's path.

Oh? Then how does the shell find it, pray tell?
Or `which` for that matter?

Not that parsing the PATH env string, pwd, argv[0]
and a mess of symlinks & NFS mounts is easy or fun.

argv[0] has contained the pgm invocation name
from time immemorial [K&R] :) Now at least,
Linux & FreeBSD give the invocation path:

main (int argc, char *argv[]) {
printf ("%s \n", argv[0]) ;

Quote:}

-- Robert

by **Grant Edwar** » Sun, 21 Oct 2001 01:24:49

> [/bin vs /usr/package argument snipped]
>> d) Historically, there's no reliable way to
>> _find_ the executable's path.

> Oh? Then how does the shell find it, pray tell?

Pray tell, can you show me how/where the shell can tell you the
full pathname of the executable file associated with a
specified process? That is, after all, the question at hand --
not "what file would the shell execute if I typed 'foo'?"

Quote:> Or `which` for that matter?

Which is doing the same thing the shell does -- which is not
what we're trying to do.

Quote:> Not that parsing the PATH env string, pwd, argv[0]
> and a mess of symlinks & NFS mounts is easy or fun.

> argv[0] has contained the pgm invocation name
> from time immemorial [K&R]

Assuming whoever called exec() put it there. The caller of
exec() can put anything they want in argv[0]. Convention is to
put the name of the program there. It may be something else
entirely. It may not be a complete path, and if multiple files
with than name exists you have no way of knowing which one is
the right one.

If you search PATH for that name, you can _probably_ find it,
but it's not something I'd depend on.

--
Grant Edwards grante Yow! Fold, fold,
at FOLD!! FOLDING many items!!
visi.com

by **Grant Edwar** » Sun, 21 Oct 2001 01:36:07

>> > The argument in the FAQ is pretty weak, basically boiling down to
>> > "This is considered to be bad form." Well excuuuse me!

>> You're excused. Go ahead an do it if you want. It's possible
>> that Unix progrmmers over the past 30 years were all wrong, and
>> you're right.

> Since I've been a Unix programmer for twenty five years they can't
> *all* have been wrong,

Touch! :)

Quote:>> It is considered bad form.

>> 1) That means that if you do it that way, your program won't
>> work the way the rest of the system does. In the SW
>> engineering classes I took the definition of a bug is "when
>> a program doesn't do what a user reasonably expects it to
>> do." That was the only useful thing I learned in those
>> classes.

>> On a Unix system, a reasonable user will not exepct that
>> the location of configuration files depends on the location
>> of the executable. If your program does so, it is therefore
>> a bug. It will cause problems for users.

> Reasonable users don't care about the location of the configuration
> files.

Huh? How does configuration data get put into the files if
users don't put them there?

Quote:> They have no expectation one way or another. They expect the
> application to perform the task for which it was designed.

Including obeying the specifications I placed in the
configuration files.

Quote:>> a) It's a very useful thing to be able to put executable
>> stuff in a read-only filesystem and share it amongst
>> hosts. This precludes putting configuration data in the
>> same location, since it generally needs to be both
>> writable and host-specific.

> It does not preclude this at all, in general if the executable
> is found in a directory such as <whatever>/usr/bin/foo the
> program can look in <whatever>/var/lib/foo/ for configuration
> files. If <whatever> happens to be the empty string the
> configuration files will be found on the writable /var
> filesystem.

What if <whatever> is on a read-only filesystem? What if
<whatever> is on a system-wide fileserver and isn't
host-specific?

Quote:>> b) Placing configuration files in a seperate location makes
>> it far easier to upgrade/reinstall the OS or program
>> without loosing the configuration data.

> Per-user configuration data is a separate issue, and of course belongs
> in the user's home directory. We're talking about system-wide
> configuration files,

If they're not host specific, and you don't want them to be
writable, then you're right. I prefer my configuration files
to be writable and generally host-specific.

Quote:> such as those that appear in /etc - the files that are
> installed or created when the program is installed, not while
> it is running.

Well, I change stuff in /etc while programs are running, but I
don't see that that matters.

Quote:>> c) Putting all of the configuration files in known,
>> predicatable locations makes it easy to take a
>> "snapshot" of your system configuration without having
>> to save gigabytes of executable images that you don't
>> care about. IOW, you don't have to back up /usr/bin as
>> often (or at all, on some systems) compared with /etc or
>> the user home directories.

> The relative method doesn't preclude a program from installing its
> configuration files in /etc, as demonstrated by my example above.
> What it does do is allow multiple versions to coexist.

There are other ways to do the multiple version thing.

Quote:>> d) Historically, there's no reliable way to _find_ the
>> executable's path.

> This is true in theory

It's true in theory, historically. On Linux it's false (even
in theory) if you've got the /proc filesystem enabled.
/proc/[pid]/exe is a symlink to the executable file.

Quote:> but irrelevant in practice. If the program's installation is
> screwed up to the point that it can't find its own executable
> you go in and fix it, like any other bug.

I quite often run executables that are in directories that are
not in the PATH. That would break your program. I would be
pretty annoyed with a program if the executable had to be in a
specific directory for it to run.

--
Grant Edwards grante Yow! It's so OBVIOUS!!
at
visi.com

Very Computer

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable

How to get the full path of an executable