Hi All,

I m building a library which requires the full path of the program to
which it is linked. How could I do it?

I can't use argv for sure, because this requires user program to be
aware of the library.

The way to find should be portable.

Besides, argv[0] doesn't give the full path. And a program can be ran
using using relative path so, getting the full path is really a hard
process using argv[0].

For eg.
[Prasad@prasadjoshi test]$ cat a_program.c
#include<stdio.h>

void afun ()
{
printf ( "\nIn afun ().\n" );
}

int main ( int argc, char *argv[] )
{
char cwd[100] ;
//intitialize_call_graph ( argv[0] );
getcwd ( cwd, 100 ) ;
printf ( "\ncwd = %s, name = %s \n", cwd, argv[0] ) ;
afun () ;
}

[Prasad@prasadjoshi test]$ ./a.out
cwd = /home/Prasad/programs/c/lsp/test, name = ./a.out
In afun ().

[Prasad@prasadjoshi test]$ ../test/a.out
cwd = /home/Prasad/programs/c/lsp/test, name = ../test/a.out
In afun ().

[Prasad@prasadjoshi test]$ ../../lsp/test/a.out
cwd = /home/Prasad/programs/c/lsp/test, name = ../../lsp/test/a.out
In afun ().

[Prasad@prasadjoshi lsp]$ test/a.out
cwd = /home/Prasad/programs/c/lsp, name = test/a.out
In afun ().

There has to be some other way to do it.

Thanks and regards,
Prasad.

[ Post a follow-up to this message ]

Prasad wrote:

> Hi All,
>
> I m building a library which requires the full path of the program to
> which it is linked. How could I do it?

Have you tried google?

Search in this group for 'path' in the subject over the past three months
and you should find a couple of discussions.

(But are you sure you really need it?)

--
Bill Medland

[ Post a follow-up to this message ]

>I m building a library which requires the full path of the program to
>which it is linked. How could I do it?

How much incentive is there for someone to maliciously make your
program determine the *WRONG* full path, and what happens if it does?
(If this program is going to be setuid, you're really asking for trouble.)

>I can't use argv for sure, because this requires user program to be
>aware of the library.
>
>The way to find should be portable.
>
>Besides, argv[0] doesn't give the full path.

argv[0] does not necessarily give anything remotely related to the
path.  argv[0] and the name of the program are passed as separate
arguments to the exec*() family.  For example, program = "/bin/ls",
argv[0] = "Copyright 2006 /// Pirates Die in a Fire"

>And a program can be ran
>using using relative path so, getting the full path is really a hard
>process using argv[0].

Prepending the current working directory to the relative path if
it's not absolute isn't "a really hard process", except for the
problem that argv[0] can be entirely fake.  The case where the
executable is found with $PATH is more of a problem, especially
when argv[0] and $PATH are both entirely fake.

The value of $PATH passed to your program need not have anything to
do with the path used to search for the program.

>For eg.
>[Prasad@prasadjoshi test]$ cat a_program.c
>#include<stdio.h>
>
>void afun ()
>{
>printf ( "\nIn afun ().\n" );
>}
>
>int main ( int argc, char *argv[] )
>{
>char cwd[100] ;
>//intitialize_call_graph ( argv[0] );
>getcwd ( cwd, 100 ) ;
>printf ( "\ncwd = %s, name = %s \n", cwd, argv[0] ) ;
>afun () ;
>}
>
>[Prasad@prasadjoshi test]$ ./a.out
>cwd = /home/Prasad/programs/c/lsp/test, name = ./a.out
>In afun ().
>
>[Prasad@prasadjoshi test]$ ../test/a.out
>cwd = /home/Prasad/programs/c/lsp/test, name = ../test/a.out
>In afun ().
>
>[Prasad@prasadjoshi test]$ ../../lsp/test/a.out
>cwd = /home/Prasad/programs/c/lsp/test, name = ../../lsp/test/a.out
>In afun ().
>
>[Prasad@prasadjoshi lsp]$ test/a.out
>cwd = /home/Prasad/programs/c/lsp, name = test/a.out
>In afun ().
>
>There has to be some other way to do it.

Most of the reasons to do it are bad.  Particularly, if you insist
on trying to put executables and writable configuration files in
the same directory, that's a very bad reason.

[ Post a follow-up to this message ]

Hi All,
Thanks a lot for giving reply.

Let me tell u why I need it...
We have an application on LINUX (developed by us), now we want to
generate the call graphs of it, the call graphs should be dynamic.

So, what I did is, used BFD library to open the executable and used
instrument-functions (functions called automatically whenever any
function is called). To these instrument functions a pointer to
function which will be called is passed). Using this pointer and bfd
library I could map the pointer to it's name. Along with it I am also
loging some other information like current time etc.

Now, BFD library need full path of the executable to open it. So, I
need that full path in my library. This library will just be used for
generating call graphs along with to log more information like time
taken by each funtion etc. So, this library will not be shipped to
customer.

Hence, I need to find the full path of the program to which my library
is linked.

Thanks and regards,
Prasad.
Gordon Burditt wrote: 
>
> How much incentive is there for someone to maliciously make your
> program determine the *WRONG* full path, and what happens if it does?
> (If this program is going to be setuid, you're really asking for trouble.)
> 
>
> argv[0] does not necessarily give anything remotely related to the
> path.  argv[0] and the name of the program are passed as separate
> arguments to the exec*() family.  For example, program = "/bin/ls",
> argv[0] = "Copyright 2006 /// Pirates Die in a Fire"
> 
>
> Prepending the current working directory to the relative path if
> it's not absolute isn't "a really hard process", except for the
> problem that argv[0] can be entirely fake.  The case where the
> executable is found with $PATH is more of a problem, especially
> when argv[0] and $PATH are both entirely fake.
>
> The value of $PATH passed to your program need not have anything to
> do with the path used to search for the program.
> 
>
> Most of the reasons to do it are bad.  Particularly, if you insist
> on trying to put executables and writable configuration files in
> the same directory, that's a very bad reason.

[ Post a follow-up to this message ]

On 21 Dec 2006 23:05:28 -0800
"Prasad" <prasadjoshi124@gmail.com> wrote:

> Hence, I need to find the full path of the program to which my library
> is linked.

There is no portable way to do this. On Linux, you can look
at /proc/"pid"/exe which is a symlink to the executable.

--
Stefaan A Eeckels
--
When the need is strong, there are those who will believe anything.
-- Arnold Lobel

[ Post a follow-up to this message ]

"Prasad" <prasadjoshi124@gmail.com> writes:

> Hi All,
> Thanks a lot for giving reply.
>
> Let me tell u why I need it...
> We have an application on LINUX (developed by us), now we want to
> generate the call graphs of it, the call graphs should be dynamic.
>
> So, what I did is, used BFD library to open the executable and used
> instrument-functions (functions called automatically whenever any
> function is called). To these instrument functions a pointer to
> function which will be called is passed). Using this pointer and bfd
> library I could map the pointer to it's name. Along with it I am also
> loging some other information like current time etc.
>
> Now, BFD library need full path of the executable to open it. So, I
> need that full path in my library. This library will just be used for
> generating call graphs along with to log more information like time
> taken by each funtion etc. So, this library will not be shipped to
> customer.
>
> Hence, I need to find the full path of the program to which my library
> is linked.

[..snip..]

On Linux one might use the something like:

<self.c>
#define _GNU_SOURCE
#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <unistd.h>

int main (void)
{
int ret, len;
pid_t pid;
char path[PATH_MAX + 1];
char proc_path[PATH_MAX + 1];

pid = getpid ();
len = snprintf (proc_path, sizeof (proc_path), "/proc/%d/exe", pid);
if ((size_t) len > sizeof (proc_path)) {
fprintf (stderr, "snprintf failed (length %d, max %d)\n",
len, sizeof (proc_path));
exit (EXIT_FAILURE);
}

ret = readlink (proc_path, path, sizeof (path));
if (ret == -1) {
err (1, "readlink failed");
}

printf ("self path = `%s'\n", path);
exit (EXIT_SUCCESS);
}
</self.c>

--
vale

[ Post a follow-up to this message ]

Stefaan A Eeckels <hoendech@ecc.lu> writes:

>On 21 Dec 2006 23:05:28 -0800
>"Prasad" <prasadjoshi124@gmail.com> wrote:
 
[vbcol=seagreen]
>There is no portable way to do this. On Linux, you can look
>at /proc/"pid"/exe which is a symlink to the executable.

getexecname() or readlink of /proc/self/path/a.out will find this
information in Solaris.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

malc <malc@pulsesoft.com> writes:

>    char path[PATH_MAX + 1];
>    char proc_path[PATH_MAX + 1];

Nit: PATH_MAX is supposed to include the trailing '\0'; why do you think
they made this a manifest constant, other than to use it directly
in your program?

>    pid = getpid ();
>    len = snprintf (proc_path, sizeof (proc_path), "/proc/%d/exe", pid);
>    if ((size_t) len > sizeof (proc_path)) {
>        fprintf (stderr, "snprintf failed (length %d, max %d)\n",
>                 len, sizeof (proc_path));
>        exit (EXIT_FAILURE);
>    }

>    ret = readlink (proc_path, path, sizeof (path));
>    if (ret == -1) {
>        err (1, "readlink failed");
>    }

>    printf ("self path = `%s'\n", path);

Error: you are assuming that readlink returns a 0 terminated path;
that is not "a portable assumption".

After checking ret != -1, you need to do this:

proc_path[ret] = '\0';

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

"matevzb" <matevzb@gmail.com> writes:

>    char buf[PATH_MAX+1], buf2[PATH_MAX+1];
>    char resolved_path[PATH_MAX+1];

Nit: PATH_MAX, not PATH_MAX + 1.


>    if (getcwd (buf, PATH_MAX) == NULL)
>    {
>        printf ("ERROR\n");
>        return EXIT_FAILURE;
>    }

Note that getcwd could return a value longer than PATH_MAX on some
OSes (but will fail with an error if your buffer is too small)

>    else
>    {
>        printf ("path='%s' argv[0]='%s'\n", buf, argv[0]);
>        if (argv[0][0] == '/')

Unfortunately, argv[0] is not at all reliable.

Take the following program and calling it "printarg0":

#include <stdio.h>

int
main(int argc, char **argv)
{
(void) printf("argv[0] is \"%s\"\n", argv[0] ? argv[0] : "(null)
");
}

and run it with zsh:

zsh$ ./printarg0
argv[0] is "./printarg0"
zsh$ $PWD/printarg0
argv[0] is "/home/casper/src/printarg0"
zsh$ ARGV0=/bin/sh ./printarg0
argv[0] is "/bin/sh"
zsh$ ARGV0= ./printarg0
argv[0] is ""

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

On Dec 22, 2:06 pm, Casper H.S. Dik <Casper....@Sun.COM> wrote:
> "matevzb" <mate...@gmail.com> writes: 
> Nit: PATH_MAX, not PATH_MAX + 1.
Sorry, work habit...
> Note that getcwd could return a value longer than PATH_MAX on some
> OSes (but will fail with an error if your buffer is too small)
True, I'm aware of this , but didn't want to post too much at once. =)
> and run it with zsh:
>
> zsh$ ./printarg0
> argv[0] is "./printarg0"
> zsh$ $PWD/printarg0
> argv[0] is "/home/casper/src/printarg0"
> zsh$ ARGV0=/bin/sh ./printarg0
> argv[0] is "/bin/sh"
> zsh$ ARGV0= ./printarg0
> argv[0] is ""
>
argv!... I mean argh! I wasn't aware of this "feature". Is this
zsh-specific or does it apply to other shells as well? In bash it seems
to work okay.
--
WYCIWYG - what you C is what you get

[ Post a follow-up to this message ]