bug-gnulib
[Top][All Lists]
Advanced

[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:38:49 +0100

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.


>     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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]