On Fri, Dec 24, 2010 at 10:41 PM, Bruno Haible <br...@clisp.org> wrote: > Hi, > Given B, you can determine C, D, E, by assuming the current directory > and $PATH have not changed since the program was launched.
Or better, in a lot of system when the library is loaded you could run some kind of constructor/init code; and thus save current dir at initial time and current $PATH. > But given A only, one cannot determine B, C, D, E. And unfortunately, > on many Unix platforms, A is the only thing you can get. > > What can we reasonably do with this? > > (a) We could create a new module that exports functions > > /* Returns the base name of argv[0], if known. */ > const char *get_program_invocation_short_name (); > > /* Returns the truncated base name of argv[0], if known. */ > const char *get_program_invocation_short_name_truncated (); > size_t get_program_invocation_short_name_truncation_length (); > > /* Return argv[0], without resolving symlinks or current directory > if possible. */ > const char *get_program_invocation_name (); > > /* Return argv[0] as a canonical filename. Assumes that the current > directory and $PATH have not changed since the program was launched. */ > const char *get_program_canonicalized_name (); > > Of course these functions would cache their respective result once it has > been determined. > > And of course there are platforms, like Interix, NonStop Kernel, or Haiku, > where all functions will return NULL. > > (b) We can observe that these proposed functions would still have > portability pitfalls: > - truncation of the short name, > - differences regarding relative filenames and symlinks, > - differences regarding the ".exe" suffix on Windows. > Decide that it is better to have no gnulib API at all than an API that > has portability problems. > > What do you think? We could at least in all the case implement getprogname/setprogname what is a well known api, and in gnulib error use the maximal information possible to get full program name. Bastien
