Finding current executable s path without proc self exe

Question

It seems to me that Linux has it easy with  proc self exe  But I d like to know if there is a convenient way to find the current application s directory in C C   with cross-platform interfaces  I ve seen some projects mucking around with argv 0   but it doesn t seem entirely reliable    If you ever had to support  say  Mac OS X  which doesn t have  proc   what would you have done  Use  ifdefs to isolate the platform-specific code  NSBundle  for example   Or try to deduce the executable s path from argv 0    PATH and whatnot  risking finding bugs in edge cases

User · Answer

The whereami library by Gregory Pakosz implements this for a variety of platforms  using the APIs mentioned in mark4o s post  This is most interesting if you  quot just quot  need a solution that works for a portable project and are not interested in the peculiarities of the various platforms  At the time of writing  supported platforms are   Windows Linux Mac iOS Android QNX Neutrino FreeBSD NetBSD DragonFly BSD SunOS  The library consists of whereami c and whereami h and is licensed under MIT and WTFPL2  Drop the files into your project  include the header and use it   include  quot whereami h quot   int main       int length   wai getExecutablePath NULL  0  NULL     char  path    char  malloc length   1     wai getExecutablePath path  length   amp dirname length     path length      0      printf  quot My path   s quot   path      free path     return 0

User · Answer

An alternative on Linux to using either  proc self exe or argv 0  is using the information passed by the ELF interpreter  made available by glibc as such    include  lt stdio h gt   include  lt sys auxv h gt   int main int argc  char   argv        printf   s n    char   getauxval AT EXECFN        return 0       Note that getauxval is a glibc extension  and to be robust you should check so that it doesn t return NULL  indicating that the ELF interpreter hasn t provided the AT EXECFN parameter   but I don t think this is ever actually a problem on Linux

User · Answer

Making this work reliably across platforms requires using  ifdef statements  The below code finds the executable s path in Windows  Linux  MacOS  Solaris or FreeBSD  although FreeBSD is untested   It uses Boost 1 55 0  or later  to simplify the code  but it s easy enough to remove if you want  Just use defines like  MSC VER and   linux as the OS and compiler require   include  lt string gt   include  lt boost predef os h gt    if  BOOST OS WINDOWS     include  lt stdlib h gt   elif  BOOST OS SOLARIS     include  lt stdlib h gt     include  lt limits h gt   elif  BOOST OS LINUX     include  lt unistd h gt     include  lt limits h gt   elif  BOOST OS MACOS     include  lt mach-o dyld h gt   elif  BOOST OS BSD FREE     include  lt sys types h gt     include  lt sys sysctl h gt   endif        Returns the full path to the currently running executable     or an empty string in case of failure      std  string getExecutablePath          if  BOOST OS WINDOWS          char  exePath          if   get pgmptr  amp exePath     0              exePath    quot  quot        elif  BOOST OS SOLARIS          char exePath PATH MAX           if  realpath getexecname    exePath     NULL              exePath 0      0        elif  BOOST OS LINUX          char exePath PATH MAX           ssize t len     readlink  quot  proc self exe quot   exePath  sizeof exePath            if  len    -1    len    sizeof exePath               len   0          exePath len      0        elif  BOOST OS MACOS          char exePath PATH MAX           uint32 t len   sizeof exePath           if   NSGetExecutablePath exePath   amp len     0                exePath 0      0      buffer too small               else                  resolve symlinks        if possible             char  canonicalPath   realpath exePath  NULL               if  canonicalPath    NULL                    strncpy exePath canonicalPath len                   free canonicalPath                                elif  BOOST OS BSD FREE          char exePath 2048           int mib 4    mib 0    CTL KERN   mib 1    KERN PROC   mib 2    KERN PROC PATHNAME   mib 3    -1          size t len   sizeof exePath           if  sysctl mib  4  exePath   amp len  NULL  0     0              exePath 0      0        endif         return std  string exePath      The above version returns full paths including the executable name  If instead you want the path without the executable name   include boost filesystem hpp gt  and change the return statement to  return strlen exePath  gt 0   boost  filesystem  path exePath  remove filename   make preferred   string     std  string

User · Answer

But I d like to know if there is a convenient way to find the current application s directory in C C   with cross-platform interfaces   You cannot do that  at least on Linux  Since an executable could  during execution of a process running it  rename 2  its file path to a different directory  of the same file system   See also syscalls 2  and inode 7   On Linux  an executable could even  in principle  remove 3  itself by calling unlink 2   The Linux kernel should then keep the file allocated till no process references it anymore  With proc 5  you could do weird things  e g  rename 2  that  proc self exe file  etc     In other words  on Linux  the notion of a  quot current application s directory quot  does not make any sense  Read also Advanced Linux Programming and Operating Systems  Three Easy Pieces for more  Look also on OSDEV for several open source operating systems  including FreeBSD or GNU Hurd   Several of them provide an interface  API  close to POSIX ones  Consider using  with permission  cross-platform C   frameworks like Qt or POCO  perhaps contributing to them by porting them to your favorite OS

User · Answer

Well  of course  this doesn t apply to all projects  Still  QCoreApplication  applicationFilePath   never failed me in 6 years of C   Qt development  Of course  one should read documentation thoroughly before attempting to use it   Warning  On Linux  this function will try to get the path from the  proc file system  If that fails  it assumes that argv 0  contains the absolute file name of the executable  The function also assumes that the current directory has not been changed by the application   To be honest  I think that  ifdef and other solutions like that shouldn t be used in modern code at all  I m sure that smaller cross-platform libraries also exist  Let them encapsulate all that platform-specific stuff inside

User · Answer

Just my two cents  You can find the current application s directory in C C   with cross-platform interfaces by using this code  void getExecutablePath char    path  unsigned int   pathLength           Early exit when invalid out-parameters are passed     if   checkStringOutParameter path  pathLength                 return          if defined SYSTEM LINUX         Preallocate PATH MAX  e g   4096  characters and hope the executable path isn t longer  including null byte      char exePath PATH MAX           Return written bytes  indicating if memory was sufficient     int len   readlink  quot  proc self exe quot   exePath  PATH MAX        if  len  lt   0    len    PATH MAX     memory not sufficient or general error occured               invalidateStringOutParameter path  pathLength           return                Copy contents to caller  create caller ownership     copyToStringOutParameter exePath  len  path  pathLength     elif defined SYSTEM WINDOWS         Preallocate MAX PATH  e g   4095  characters and hope the executable path isn t longer  including null byte      char exePath MAX PATH           Return written bytes  indicating if memory was sufficient     unsigned int len   GetModuleFileNameA GetModuleHandleA 0x0   exePath  MAX PATH       if  len    0     memory not sufficient or general error occured               invalidateStringOutParameter path  pathLength           return                Copy contents to caller  create caller ownership     copyToStringOutParameter exePath  len  path  pathLength     elif defined SYSTEM SOLARIS         Preallocate PATH MAX  e g   4096  characters and hope the executable path isn t longer  including null byte      char exePath PATH MAX           Convert executable path to canonical path  return null pointer on error     if  realpath getexecname    exePath     0x0                invalidateStringOutParameter path  pathLength           return                Copy contents to caller  create caller ownership     unsigned int len   strlen exePath       copyToStringOutParameter exePath  len  path  pathLength     elif defined SYSTEM DARWIN         Preallocate PATH MAX  e g   4096  characters and hope the executable path isn t longer  including null byte      char exePath PATH MAX        unsigned int len    unsigned int PATH MAX          Obtain executable path to canonical path  return zero on success     if   NSGetExecutablePath exePath   amp len     0                   Convert executable path to canonical path  return null pointer on error         char   realPath   realpath exePath  0x0            if  realPath    0x0                        invalidateStringOutParameter path  pathLength               return                        Copy contents to caller  create caller ownership         unsigned int len   strlen realPath           copyToStringOutParameter realPath  len  path  pathLength            free realPath             else    len is initialized with the required number of bytes  including zero byte                char   intermediatePath    char   malloc sizeof char    len               Convert executable path to canonical path  return null pointer on error         if   NSGetExecutablePath intermediatePath   amp len     0                        free intermediatePath               invalidateStringOutParameter path  pathLength               return                     char   realPath   realpath intermediatePath  0x0            free intermediatePath               Check if conversion to canonical path succeeded         if  realPath    0x0                        invalidateStringOutParameter path  pathLength               return                        Copy contents to caller  create caller ownership         unsigned int len   strlen realPath           copyToStringOutParameter realPath  len  path  pathLength            free realPath           elif defined SYSTEM FREEBSD         Preallocate characters and hope the executable path isn t longer  including null byte      char exePath 2048        unsigned int len   2048       int mib       CTL KERN  KERN PROC  KERN PROC PATHNAME  -1            Obtain executable path by syscall     if  sysctl mib  4  exePath   amp len  0x0  0     0                invalidateStringOutParameter path  pathLength           return                Copy contents to caller  create caller ownership     copyToStringOutParameter exePath  len  path  pathLength     else         If no OS could be detected     degrade gracefully     invalidateStringOutParameter path  pathLength     endif    You can take a look in detail here

User · Answer

If you re writing GPLed code and using GNU autotools  then a portable way that takes care of the details on many OSes  including Windows and macOS  is gnulib s relocatable-prog module

User · Answer

You can use argv 0  and analyze the PATH environment variable   Look at   A sample of a program that can find itself

User · Answer

Depending on the version of QNX Neutrino  there are different ways to find the full path and name of the executable file that was used to start the running process  I denote the process identifier as  lt PID gt   Try the following    If the file  proc self exefile exists  then its contents are the requested information  If the file  proc  lt PID gt  exefile exists  then its contents are the requested information  If the file  proc self as exists  then    open   the file  Allocate a buffer of  at least  sizeof procfs debuginfo     POSIX PATH MAX  Give that buffer as input to devctl fd  DCMD PROC MAPDEBUG BASE      Cast the buffer to a procfs debuginfo   The requested information is at the path field of the procfs debuginfo structure  Warning  For some reason  sometimes  QNX omits the first slash   of the file path  Prepend that   when needed  Clean up  close the file  free the buffer  etc     Try the procedure in 3  with the file  proc  lt PID gt  as  Try dladdr dlsym RTLD DEFAULT   main     amp dlinfo  where dlinfo is a Dl info structure whose dli fname might contain the requested information    I hope this helps

User · Answer

If you ever had to support  say  Mac OS X  which doesn t have  proc   what would you have done  Use  ifdefs to isolate the platform-specific code  NSBundle  for example    Yes  isolating platform-specific code with  ifdefs is the conventional way this is done  Another approach would be to have a have clean  ifdef-less header which contains function declarations and put the implementations in platform specific source files  For example  check out how POCO  Portable Components  C   library does something similar for their Environment class

User · Answer

The use of  proc self exe is non-portable and unreliable    On my Ubuntu 12 04 system  you must be root to read follow the symlink    This will make the Boost example and probably the whereami   solutions posted fail  This post is very long but discusses the actual issues and presents code which actually works along with validation against a test suite  The best way to find your program is to retrace the same steps the system uses  This is done by using argv 0  resolved against file system root  pwd  path environment and considering symlinks  and pathname canonicalization   This is from memory but I have done this in the past successfully and tested it in a variety of different situations   It is not guaranteed to work  but if it doesn t you probably have much bigger problems and it is more reliable overall than any of the other methods discussed    There are situations on a Unix compatible system in which proper handling of argv 0  will not get you to your program but then you are executing in a certifiably broken environment   It is also fairly portable to all Unix derived systems since around 1970 and even some non-Unix derived systems as it basically relies on libc   standard functionality and standard command line functionality   It should work on Linux  all versions   Android  Chrome OS  Minix  original Bell Labs Unix  FreeBSD  NetBSD  OpenBSD  BSD x x  SunOS  Solaris  SYSV  HP-UX  Concentrix  SCO  Darwin  AIX  OS X  NeXTSTEP  etc   And with a little modification probably VMS  VM CMS  DOS Windows  ReactOS  OS 2  etc    If a program was launched directly from a GUI environment  it should have set argv 0  to an absolute path  Understand that almost every shell on every Unix compatible operating system that has ever been released basically finds programs the same way and sets up the operating environment almost the same way  with some optional extras    And any other program that launches a program is expected to create the same environment  argv  environment strings  etc   for that program as if it were run from a shell  with some optional extras  A program or user can setup an environment that deviates from this convention for other subordinate programs that it launches but if it does  this is a bug and the program has no reasonable expectation that the subordinate program or its subordinates will function correctly  Possible values of argv 0  include    path to executable     absolute path    bin executable     relative to pwd bin executable     relative to pwd   foo     relative to pwd executable     basename  find in path bin  executable     relative to pwd  non-canonical src    bin executable     relative to pwd  non-canonical  backtracking bin   echoargc     relative to pwd  non-canonical  Values you should not see     bin executable     rewritten before your program runs   user bin executable     rewritten before your program runs alias     rewritten before your program runs  shellvariable     rewritten before your program runs  foo      wildcard  rewritten before your program runs  not very useful  foo      wildcard  rewritten before your program runs  not very useful  In addition  these may contain non-canonical path names and multiple layers of symbolic links   In some cases  there may be multiple hard links to the same program    For example   bin ls   bin ps   bin chmod   bin rm  etc  may be hard links to  bin busybox  To find yourself  follow the steps below   Save pwd  PATH  and argv 0  on entry to your program  or initialization of your library  as they may change later   Optional  particularly for non-Unix systems  separate out but don t discard the pathname host user drive prefix part  if present  the part which often precedes a colon or follows an initial  quot    quot    If argv 0  is an absolute path  use that as a starting point    An absolute path probably starts with  quot   quot  but on some non-Unix systems it might start with  quot  quot  or a drive letter or name prefix followed by a colon   Else if argv 0  is a relative path  contains  quot   quot  or  quot  quot  but doesn t start with it  such as  quot       bin foo quot   then combine pwd  quot   quot  argv 0   use present working directory from when program started  not current    Else if argv 0  is a plain basename  no slashes   then combine it with each entry in PATH environment variable in turn and try those and use the first one which succeeds   Optional  Else try the very platform specific  proc self exe   proc curproc file  BSD   and  char   getauxval AT EXECFN   and dlgetname      if present   You might even try these before argv 0 -based methods  if they are available and you don t encounter permission issues   In the somewhat unlikely event  when you consider all versions of all systems  that they are present and don t fail  they might be more authoritative   Optional  check for a path name passed in using a command line parameter   Optional  check for a pathname in the environment explicitly passed in by your wrapper script  if any   Optional  As a last resort try environment variable  quot   quot    It might point to a different program entirely  such as the users shell   Resolve symlinks  there may be multiple layers    There is the possibility of infinite loops  though if they exist your program probably won t get invoked   Canonicalize filename by resolving substrings like  quot  foo    bar  quot  to  quot  bar  quot    Note this may potentially change the meaning if you cross a network mount point  so canonization is not always a good thing   On a network server   quot    quot  in symlink may be used to traverse a path to another file in the server context instead of on the client   In this case  you probably want the client context so canonicalization is ok    Also convert patterns like   quot     quot  to  quot   quot  and  quot    quot  to  quot   quot   In shell  readlink --canonicalize will resolve multiple symlinks and canonicalize name    Chase may do similar but isn t installed    realpath   or canonicalize file name    if present  may help    If realpath   doesn t exist at compile time  you might borrow a copy from a permissively licensed library distribution  and compile it in yourself rather than reinventing the wheel   Fix the potential buffer overflow  pass in sizeof output buffer  think strncpy   vs strcpy    if you will be using a buffer less than PATH MAX    It may be easier just to use a renamed private copy rather than testing if it exists    Permissive license copy from android darwin bsd  https   android googlesource com platform bionic   f077784 libc upstream-freebsd lib libc stdlib realpath c Be aware that multiple attempts may be successful or partially successful and they might not all point to the same executable  so consider verifying your executable  however  you may not have read permission     if you can t read it  don t treat that as a failure   Or verify something in proximity to your executable such as the  quot    lib  quot  directory you are trying to find  You may have multiple versions  packaged and locally compiled versions  local and network versions  and local and USB-drive portable versions  etc  and there is a small possibility that you might get two incompatible results from different methods of locating   And  quot   quot  may simply point to the wrong program  A program using execve can deliberately set argv 0  to be incompatible with the actual path used to load the program and corrupt PATH   quot   quot   pwd  etc  though there isn t generally much reason to do so  but this could have security implications if you have vulnerable code that ignores the fact that your execution environment can be changed in variety of ways including  but not limited  to this one  chroot  fuse filesystem  hard links  etc    It is possible for shell commands to set PATH but fail to export it  You don t necessarily need to code for non-Unix systems but it would be a good idea to be aware of some of the peculiarities so you can write the code in such a way that it isn t as hard for someone to port later   Be aware that some systems  DEC VMS  DOS  URLs  etc   might have drive names or other prefixes which end with a colon such as  quot C  quot    quot sys drive  foo bar quot   and  quot file    foo bar baz quot    Old DEC VMS systems use  quot   quot  and  quot   quot  to enclose the directory portion of the path though this may have changed if your program is compiled in a POSIX environment   Some systems  such as VMS  may have a file version  separated by a semicolon at the end    Some systems use two consecutive slashes as in  quot   drive path to file quot  or  quot user host  path to file quot   scp command  or  quot file   hostname path to file quot   URL    In some cases  DOS and Windows   PATH might have different separator characters      quot   quot  vs  quot   quot  and  quot  quot  vs  quot   quot  for a path separator   In csh tsh there is  quot path quot   delimited with spaces  and  quot PATH quot  delimited with colons but your program should receive PATH so you don t need to worry about path    DOS and some other systems can have relative paths that start with a drive prefix    C foo exe refers to foo exe in the current directory on drive C  so you do need to lookup current directory on C  and use that for pwd  An example of symlinks and wrappers on my system   usr bin google-chrome is symlink to  etc alternatives google-chrome  which is symlink to  usr bin google-chrome-stable which is symlink to  opt google chrome google-chrome which is a bash script which runs  opt google chome chrome  Note that user bill posted a link above to a program at HP that handles the three basic cases of argv 0     It needs some changes  though   It will be necessary to rewrite all the strcat   and strcpy   to use strncat   and strncpy     Even though the variables are declared of length PATHMAX  an input value of length PATHMAX-1 plus the length of concatenated strings is  gt  PATHMAX and an input value of length PATHMAX would be unterminated  It needs to be rewritten as a library function  rather than just to print out results  It fails to canonicalize names  use the realpath code I linked to above  It fails to resolve symbolic links  use the realpath code   So  if you combine both the HP code and the realpath code and fix both to be resistant to buffer overflows  then you should have something which can properly interpret argv 0   The following illustrates actual values of argv 0  for various ways of invoking the same program on Ubuntu 12 04   And yes  the program was accidentally named echoargc instead of echoargv   This was done using a script for clean copying but doing it manually in shell gets same results  except aliases don t work in script unless you explicitly enable them   cat   src echoargc c  include  lt stdlib h gt   include  lt stdio h gt   include  lt unistd h gt  main int argc  char   argv      printf  quot   argv 0    quot  s  quot  n quot   argv 0      sleep 1       in case run from desktop      tcc -o   bin echoargc   src echoargc c cd    home whitis bin echoargc   argv 0   quot  home whitis bin echoargc quot  echoargc   argv 0   quot echoargc quot  bin echoargc   argv 0   quot bin echoargc quot  bin  echoargc   argv 0   quot bin  echoargc quot  bin   echoargc   argv 0   quot bin   echoargc quot  src    bin echoargc   argv 0   quot src    bin echoargc quot  cd   bin  echo    argv 0   quot echoargc quot  e hoargc   argv 0   quot echoargc quot    echoargc   argv 0   quot   echoargc quot  cd   src    bin echoargc   argv 0   quot    bin echoargc quot  cd   junk   bin echoargc   argv 0   quot  home whitis bin echoargc quot   whitis bin echoargc   argv 0   quot  home whitis bin echoargc quot  alias echoit   bin echoargc echoit   argv 0   quot  home whitis bin echoargc quot  echoarg   bin echoargc  echoarg   argv 0   quot  home whitis bin echoargc quot  ln -s   bin echoargc junk1   junk1   argv 0   quot   junk1 quot  ln -s  home whitis bin echoargc junk2   junk2   argv 0   quot   junk2 quot  ln -s junk1 junk3   junk3   argv 0   quot   junk3 quot    gnome-desktop-item-edit --create-new   Desktop   interactive  create desktop link  then click on it   argv 0   quot  home whitis bin echoargc quot    interactive  right click on gnome application menu  pick edit menus   add menu item for echoargc  then run it from gnome menu  argv 0   quot  home whitis bin echoargc quot    cat   testargcscript 2 gt  amp 1   sed -e  s        g     bin bash   echoargc is in   bin echoargc   bin is in path shopt -s expand aliases set -v cat   src echoargc c tcc -o   bin echoargc   src echoargc c cd    home whitis bin echoargc echoargc bin echoargc bin  echoargc bin   echoargc src    bin echoargc cd   bin  echo  e hoargc   echoargc cd   src    bin echoargc cd   junk   bin echoargc  whitis bin echoargc alias echoit   bin echoargc echoit echoarg   bin echoargc  echoarg ln -s   bin echoargc junk1   junk1 ln -s  home whitis bin echoargc junk2   junk2 ln -s junk1 junk3   junk3  These examples illustrate that the techniques described in this post should work in a wide range of circumstances and why some of the steps are necessary  EDIT  Now  the program that prints argv 0  has been updated to actually find itself     Copyright 2015 by Mark Whitis   License MIT style  include  lt stdlib h gt   include  lt stdio h gt   include  lt unistd h gt   include  lt limits h gt   include  lt assert h gt   include  lt string h gt   include  lt errno h gt       quot look deep into yourself  Clarice quot   -- Hanibal Lector char findyourself save pwd PATH MAX   char findyourself save argv0 PATH MAX   char findyourself save path PATH MAX   char findyourself path separator      char findyourself path separator as string 2   quot   quot   char findyourself path list separator 8   quot   quot       could be  quot     quot  char findyourself debug 0   int findyourself initialized 0   void findyourself init char  argv0       getcwd findyourself save pwd  sizeof findyourself save pwd       strncpy findyourself save argv0  argv0  sizeof findyourself save argv0      findyourself save argv0 sizeof findyourself save argv0 -1  0     strncpy findyourself save path  getenv  quot PATH quot    sizeof findyourself save path      findyourself save path sizeof findyourself save path -1  0    findyourself initialized 1      int find yourself char  result  size t size of result      char newpath PATH MAX 256     char newpath2 PATH MAX 256      assert findyourself initialized     result 0  0     if findyourself save argv0 0   findyourself path separator        if findyourself debug  printf  quot   absolute path n quot         realpath findyourself save argv0  newpath        if findyourself debug  printf  quot   newpath   quot  s  quot  n quot   newpath        if  access newpath  F OK             strncpy result  newpath  size of result           result size of result-1  0          return 0          else       perror  quot access failed 1 quot                else if  strchr findyourself save argv0  findyourself path separator          if findyourself debug  printf  quot   relative path to pwd n quot        strncpy newpath2  findyourself save pwd  sizeof newpath2        newpath2 sizeof newpath2 -1  0      strncat newpath2  findyourself path separator as string  sizeof newpath2        newpath2 sizeof newpath2 -1  0      strncat newpath2  findyourself save argv0  sizeof newpath2        newpath2 sizeof newpath2 -1  0      realpath newpath2  newpath       if findyourself debug  printf  quot   newpath   quot  s  quot  n quot   newpath       if  access newpath  F OK             strncpy result  newpath  size of result           result size of result-1  0          return 0          else       perror  quot access failed 2 quot                else       if findyourself debug  printf  quot   searching  PATH n quot        char  saveptr      char  pathitem      for pathitem strtok r findyourself save path  findyourself path list separator    amp saveptr   pathitem  pathitem strtok r NULL  findyourself path list separator   amp saveptr             if findyourself debug gt  2  printf  quot pathitem   quot  s  quot  n quot   pathitem          strncpy newpath2  pathitem  sizeof newpath2           newpath2 sizeof newpath2 -1  0         strncat newpath2  findyourself path separator as string  sizeof newpath2           newpath2 sizeof newpath2 -1  0         strncat newpath2  findyourself save argv0  sizeof newpath2           newpath2 sizeof newpath2 -1  0         realpath newpath2  newpath          if findyourself debug  printf  quot   newpath   quot  s  quot  n quot   newpath         if  access newpath  F OK               strncpy result  newpath  size of result             result size of result-1  0            return 0                    end for     perror  quot access failed 3 quot            end else      if we get here  we have tried all three methods on argv 0  and still haven t succeeded    Include fallback methods here    return 1      main int argc  char   argv      findyourself init argv 0       char newpath PATH MAX     printf  quot   argv 0    quot  s  quot  n quot   argv 0      realpath argv 0   newpath     if strcmp argv 0  newpath     printf  quot   realpath   quot  s  quot  n quot   newpath       find yourself newpath  sizeof newpath      if 1    strcmp argv 0  newpath     printf  quot   findyourself   quot  s  quot  n quot   newpath       sleep 1       in case run from desktop       And here is the output which demonstrates that in every one of the previous tests it actually did find itself  tcc -o   bin echoargc   src echoargc c cd    home whitis bin echoargc   argv 0   quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  echoargc   argv 0   quot echoargc quot    realpath  quot  home whitis echoargc quot    findyourself  quot  home whitis bin echoargc quot  bin echoargc   argv 0   quot bin echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  bin  echoargc   argv 0   quot bin  echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  bin   echoargc   argv 0   quot bin   echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  src    bin echoargc   argv 0   quot src    bin echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  cd   bin  echo    argv 0   quot echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  e hoargc   argv 0   quot echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot    echoargc   argv 0   quot   echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  cd   src    bin echoargc   argv 0   quot    bin echoargc quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  cd   junk   bin echoargc   argv 0   quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot   whitis bin echoargc   argv 0   quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  alias echoit   bin echoargc echoit   argv 0   quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  echoarg   bin echoargc  echoarg   argv 0   quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  rm junk1 junk2 junk3 ln -s   bin echoargc junk1   junk1   argv 0   quot   junk1 quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  ln -s  home whitis bin echoargc junk2   junk2   argv 0   quot   junk2 quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot  ln -s junk1 junk3   junk3   argv 0   quot   junk3 quot    realpath  quot  home whitis bin echoargc quot    findyourself  quot  home whitis bin echoargc quot   The two GUI launches described above also correctly find the program  There is one potential pitfall   The access   function drops permissions if the program is setuid before testing    If there is a situation where the program can be found as an elevated user but not as a regular user  then there might be a situation where these tests would fail  although it is unlikely the program could actually be executed under those circumstances    One could use euidaccess   instead   It is possible  however  that it might find an inaccessable program earlier on path than the actual user could

User · Answer

Some OS-specific interfaces   Mac OS X   NSGetExecutablePath    man 3 dyld  Linux  readlink  proc self exe Solaris  getexecname   FreeBSD  sysctl CTL KERN KERN PROC KERN PROC PATHNAME -1 FreeBSD if it has procfs  readlink  proc curproc file  FreeBSD doesn t have procfs by default  NetBSD  readlink  proc curproc exe DragonFly BSD  readlink  proc curproc file  Windows  GetModuleFileName   with hModule   NULL  There are also third party libraries that can be used to get this information  such as whereami as mentioned in prideout s answer  or if you are using Qt   QCoreApplication  applicationFilePath   as mentioned in the comments  The portable  but less reliable  method is to use argv 0    Although it could be set to anything by the calling program  by convention it is set to either a path name of the executable or a name that was found using  PATH  Some shells  including bash and ksh  set the environment variable  quot   quot  to the full path of the executable before it is executed   In that case you can use getenv  quot   quot   to get it   However this is unreliable because not all shells do this  and it could be set to anything or be left over from a parent process which did not change it before executing your program

User · Answer

AFAIK  no such way   And there is also an ambiguity  what would you like to get as the answer if the same executable has multiple hard-links  quot pointing quot  to it   Hard-links don t actually  quot point quot   they are the same file  just at another place in the file system hierarchy   Once execve   successfully executes a new binary  all information about the arguments to the original program is lost

User · Answer

In addition to mark4o s answer  FreeBSD also has const char  getprogname void   It should also be available in macOS  It s available in GNU Linux through libbsd

[c++] Finding current executable's path without /proc/self/exe

Examples related to c++

Examples related to c

Examples related to linux

Examples related to macos

Examples related to executable