n Sat, Dec 25, 2010 at 4:38 PM, Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > 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.
using a c++ code snipped is the most easy way to do that. Using a constructor of a static object for instance. > >> 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 >