finding the full path of the program which ran. - Linux

This is a discussion on finding the full path of the program which ran. - Linux ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: finding the full path of the program which ran.

  1. finding the full path of the program which ran.

    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

    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.


  2. Re: finding the full path of the program which ran.

    If i have put the question on the wrong Usenet Group, then I am really
    sorry for. Please forgive me.

    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?
    >
    > 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
    >
    > 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.



  3. Re: finding the full path of the program which ran.

    On 2006-12-21, Prasad wrote:

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


    /proc/self/exe

    --
    Grant Edwards grante Yow! .. I see TOILET
    at SEATS...
    visi.com

  4. Re: finding the full path of the program which ran.

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


    This is impossible if you require an answer that is always correct
    regardless of circumstances.

    The presence of hard links and symbolic links allows for many different
    names for the "same" program. So "_the_ full path" might be ambiguous.

    Another poster recommended readlink("/proc/self/exe", ...).
    First of all, the /proc filesystem was totally optional until
    Linux 2.6, and many Linux 2.4.x systems do not have it (neither
    compiled-in, nor as a loaded kernel module) and even those that
    do have /proc might have it unmounted (for maintenance) when
    you ask. Technically /proc is still optional in linux-2.6.x,
    but nearly all non-embedded systems have it.

    Even when /proc is available and mounted, another process might
    unlink [rm or mv] the program while your process is running.
    In this case the kernel appends the string " (deleted)" to the
    pathname in /proc/self/exe. However, your library might be used
    by a program with original name "secret_app (deleted)", so after
    an unlink then /proc/self/exe would be
    "secret_app (deleted) (deleted)"; and so on. Your library cannot
    tell for sure whether the last " (deleted)" was put there by the
    kernel, or whether it was there already. The library can attempt
    an open(), stat(), or access() of the name returned by readlink(),
    but that introduces a race condition.

    Perhaps the most reliable "historical" answer is given by an
    undocumented feature of the Linux kernel. This is undocumented,
    but has been around for over ten years, and won't change soon.
    The kernel stores the literal text of the first argument to execve()
    as a character string which follows the string for the last environment
    variable. Thus (1+ strlen(environ[-1+ n_env]) + environ[-1+ n_env])
    _was_ the name that the kernel exec'd, if environ still has its
    original value. But if the process has done any putenv(), or
    otherwise modified the value of global variable 'environ',
    or overwritten the character arrays involved, then it is too late
    to take advantage of this feature.

    --

  5. Re: finding the full path of the program which ran.

    John Reiser writes:

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

    >
    > This is impossible if you require an answer that is always correct
    > regardless of circumstances.
    >
    > The presence of hard links and symbolic links allows for many different
    > names for the "same" program. So "_the_ full path" might be ambiguous.


    (snipped lots of good information)

    Never mind that the full path at link time isn't likely to be the same
    as the full path at run time.
    --
    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

  6. Re: finding the full path of the program which ran.

    On 2006-12-21, Joe Pfeiffer wrote:
    > John Reiser writes:
    >
    >> > I m building a library which requires the full path of the program to
    >> > which it is linked. How could I do it?

    >>
    >> This is impossible if you require an answer that is always correct
    >> regardless of circumstances.
    >>
    >> The presence of hard links and symbolic links allows for many different
    >> names for the "same" program. So "_the_ full path" might be ambiguous.

    >
    > (snipped lots of good information)
    >
    > Never mind that the full path at link time isn't likely to be the same
    > as the full path at run time.


    Well, he did say "is linked" rather than "was linked", so I
    assumed he wanted the current path of the current executable in
    who's context the library is executing.

    There isn't really a good, general way to find out. Most
    people who want to know are asking for the wrong reasons
    anyway. Usually when people ask "how do I find the location of
    the program's exectuable" it's becuase they're Windows
    programmers who think configuration files are stored in the
    same directory as executables.

    Under Unix that's most definitely _not_ where configuration
    files go, so there shouldn't be any real need to know.

    --
    Grant Edwards grante Yow! Jesuit priests are
    at DATING CAREER DIPLOMATS!!
    visi.com

  7. Re: finding the full path of the program which ran.

    In article <1166719239.949245.70760@i12g2000cwa.googlegroups.c om>,
    Prasad wrote:

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


    If you really need that information, you're probably doing something
    very wrong.

  8. Re: finding the full path of the program which ran.

    In article <12om2dnk8imti3d@corp.supernews.com>,
    Grant Edwards wrote:

    >Most >people who want to know are asking for the wrong reasons
    >anyway.


    Exactly!

    --
    http://www.spinics.net/lists/

  9. Re: finding the full path of the program which ran.

    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.

    ellis@no.spam wrote:
    > In article <1166719239.949245.70760@i12g2000cwa.googlegroups.c om>,
    > Prasad wrote:
    >
    > >I m building a library which requires the full path of the program to
    > >which it is linked. How could I do it?

    >
    > If you really need that information, you're probably doing something
    > very wrong.



  10. Re: finding the full path of the program which ran.

    On Thu, 21 Dec 2006 22:24:55 -0000 Grant Edwards wrote:

    | Well, he did say "is linked" rather than "was linked", so I
    | assumed he wanted the current path of the current executable in
    | who's context the library is executing.
    |
    | There isn't really a good, general way to find out. Most
    | people who want to know are asking for the wrong reasons
    | anyway. Usually when people ask "how do I find the location of
    | the program's exectuable" it's becuase they're Windows
    | programmers who think configuration files are stored in the
    | same directory as executables.
    |
    | Under Unix that's most definitely _not_ where configuration
    | files go, so there shouldn't be any real need to know.

    I see more users doing this to find resource files, such as the
    collection of dynamically loadable modules that come with the
    application. But even this should be elsewhere in Unix, such
    as /usr/share (but this varies by distribution).

    About the only thing I think the application will need to know is
    the base name it was run from. Then it can look for:
    ${HOME}/.${basename}.conf
    ${HOME}/.${basename}.d/default.conf
    ${HOME}/.etc/${basename}.conf
    ${HOME}/.etc/${basename}.d/default.conf
    /etc/${basename}.conf
    /etc/${basename}.d/default.conf
    or some such thing, and from there obtain any overrides to default
    behaviours looking for resources files. A reasonable application
    could have a list of paths to look for it's resources based on what
    is common for many major distributions of Linux and other Unix class
    systems, with tweaks and overrides to that coming from command line
    options, environment variables, and config files in the user home
    directory or /etc for system wide settings.

    If link is made so the application appears to have a different name
    than it's original file basename, then the alternate basename would
    be used in the above search. If all searches fail to find anything,
    then it could rerun the search with it's original package name as
    a fallback. It might also be prudent to do this search based on
    version variations of the application name (in shell style):
    for basename in \
    ${0} \
    ${appname}-${majorversion}.${minorversion}.${tweakversion} \
    ${appname}-${majorversion}.${minorversion} \
    ${appname}-${majorversion} \
    ${appname} ; do
    search for config file for ${basename}
    done

    I probably should write a C function to do all this searching in a
    nicely callable form for C/C++ programmers.

+ Reply to Thread