[Bug-gnulib] Re: new module: progname

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> Simon Josefsson <address@hidden> writes:
>> >    * argp.m4: New file.
>>
>> I noticed I had made some modifications in another version of the
>> file, here's what I really uses, which works on several platforms.
>>
>> I had one idea to make a 'program_invocation_name' module, so that
>> error.c could use that instead of 'program_name'.  I don't like the
>> current 'program_name' stuff, it pollute all applications that uses my
>> library.  Making a module out of it would allow other modules (and
>> applications) to rely on program_invocation_name, which is a useful
>> thing to have, but I haven't done anything about this.  Instead of
>> being declared 'extern', it should, on platforms that doesn't have
>> program_invocation_name (or a similar way to get the executable name),
>> be defined to a static string, say 'gnulib' and there could be a
>> function to set it to something else.  What do you think?
>
> What would be the benefit of calling it 'program_invocation_name', i.e.
> differently from what the 'error' module expects?

program_invocation_name is glibc standard and is documented.  Is
'program_name' used by any system/standard except gnulib error.c?  Of
course, if program_invocation_name is used, error.c should be
modified.

> int
> main (int argc, char **argv)
> {
>   /* Set program name for messages.  */
>   set_program_name (argv[0]);
>   error_print_progname = maybe_print_progname;

I think a solution that didn't require modification in application
sources would be better -- I'm using gnulib from a library.  All
applications that uses my library would have to do these modifications
using your proposal.

My proposal: for glibc systems, we have program_invocation_name so we
are done, for other systems we introduce

char *program_invocation_name = NULL;

and applications can set this, like your applications would, but if it
remains unset, for example when gnulib is used in a dlopen()'d plugin
or similar, instead of printing:

ls: foo warning

the error.c code might print

foo warning

or perhaps use "gnulib" or "2231" (pid of process) or some other
string instead of the real argv[0].

As I see it, this 1) doesn't introduce any restriction (you can still
set the program name with a macro, like the one above, and get the
exact same functionality), but it 2) allows gnulib error.c and other
code to link even if the application is unaware of gnulib conventions
and doesn't define the program_name variable.

Thanks.