[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: determining the program_invocation_name
From: |
Bastien ROUCARIES |
Subject: |
Re: determining the program_invocation_name |
Date: |
Sat, 25 Dec 2010 16:41:53 +0100 |
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
>