Re: [PATCH] progname: also set global program_invocation_name, when possible

[Bruno Haible]

Jim Meyering wrote on 2009-08-25:
> No.  That package *does* use the error module.
> However, per m4/error.m4, when building on a glibc-based system,
> error.c is not compiled.
> 
> Your addition to this comment made it misleading:
> 
>   /* On glibc systems, when the gnulib module 'error' is not used, the error()
>      function comes from libc and uses the variable program_invocation_name,
>      not program_name.  So set this variable as well.  */
> 
> I suggest removing the "when the gnulib module..." clause:
> 
>   /* On glibc systems, the error() function comes from libc and
>      uses the variable program_invocation_name, not program_name.
>      So set this variable as well.  */

You're right. I'm fixing the comment.

2009-10-04  Bruno Haible  <address@hidden>

        * lib/progname.c (set_program_name): Fix comment.
        Reported by Jim Meyering.

--- lib/progname.c.orig 2009-10-04 12:03:56.000000000 +0200
+++ lib/progname.c      2009-10-04 12:03:38.000000000 +0200
@@ -62,9 +62,9 @@
 
   program_name = argv0;
 
-  /* On glibc systems, when the gnulib module 'error' is not used, the error()
-     function comes from libc and uses the variable program_invocation_name,
-     not program_name.  So set this variable as well.  */
+  /* On glibc systems, the error() function comes from libc and uses the
+     variable program_invocation_name, not program_name.  So set this variable
+     as well.  */
 #if HAVE_DECL_PROGRAM_INVOCATION_NAME
   program_invocation_name = (char *) argv0;
 #endif


Sergey Poznyakoff wrote:
> In my opinion, that's not correct.  Libc (and gnulib's argp, FWIW) uses
> two variables: program_invocation_name, which points to the full program
> name as obtained from argv[0], and program_invocation_short_name, which
> points to the program name with all leading directories removed.  So,
> set_program_name should set program_invocation_name to arg0, and
> program_invocation_short_name to part of arg0 after the last directory
> separator.

The purpose of the assignments in progname.c is to make the libtool
artefacts disappear. Jim's patch does the right thing for
program_invocation_name, which is the variable that error() uses.

But you are right mentioning program_invocation_short_name. It too needs
to be modified, to remove libtool artefacts. I'm applying this:

2009-10-04  Bruno Haible  <address@hidden>

        * lib/progname.c (set_program_name): Also remove the "lt-" prefix from
        program_invocation_short_name.
        * modules/progname (configure.ac): Test for presence of
        program_invocation_short_name.
        Reported by Sergey Poznyakoff <address@hidden>.

--- lib/progname.c.orig 2009-10-04 12:12:28.000000000 +0200
+++ lib/progname.c      2009-10-04 12:11:09.000000000 +0200
@@ -48,7 +48,14 @@
     {
       argv0 = base;
       if (strncmp (base, "lt-", 3) == 0)
-       argv0 = base + 3;
+       {
+         argv0 = base + 3;
+         /* On glibc systems, remove the "lt-" prefix from the variable
+            program_invocation_short_name.  */
+#if HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME
+         program_invocation_short_name = (char *) argv0;
+#endif
+       }
     }
 
   /* But don't strip off a leading <dirname>/ in general, because when the user
--- modules/progname.orig       2009-10-04 12:12:28.000000000 +0200
+++ modules/progname    2009-10-04 12:11:33.000000000 +0200
@@ -9,6 +9,7 @@
 
 configure.ac:
 AC_CHECK_DECLS([program_invocation_name], [], [], [#include <errno.h>])
+AC_CHECK_DECLS([program_invocation_short_name], [], [], [#include <errno.h>])
 
 Makefile.am:
 lib_SOURCES += progname.h progname.c


Jim Meyering wrote:
> in order to make diagnostics appear like
> 
>     program_name: ....
> 
> rather than
> 
>     /abs/dir.../.libs/lt-program_name: ....
> 
> the set_program_name function must update program_invocation_name.

Yes.

> Unfortunately, when using libtool, and looking solely at argv, we cannot
> derive the true command invocation name, so we cannot determine whether
> the tool was invoked via ../../usr/bin/program, /usr/bin/program, or
> simply "program".

When installed in /usr/bin, the program does not have a libtool wrapper
script. The typical situation is in build trees: The test suite invokes
program or ./program or ../src/program, and the program's argv[0] becomes
/abs/dir.../.libs/lt-program.

Bruno