Re: determining the program_invocation_name

[Bastien ROUCARIES]

n Sat, Dec 25, 2010 at 4:38 PM, Bastien ROUCARIES
<address@hidden> wrote:
> On Fri, Dec 24, 2010 at 10:41 PM, Bruno Haible <address@hidden> 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
>