Re: getprogname and libtool

[Jim Meyering]

On Sat, Dec 17, 2016 at 3:27 PM, Bruno Haible  wrote:
> Followup to this discussion from October 2016:
>
> Jim:
>> > I did not mean to imply by that message that we should eliminate every
>> > use of the program_name module. My desire is more to avoid accidental
>> > use of it when the getprogname module would be more appropriate.
>
> Bruno:
>> Fully agree on this.
>>
>> The way I currently see it, the two modules serve different purposes
>> and it's easy to decide which one to use in which case:
>>
>>   * In a program's main() function, and associated usage() and help()
>> functions, use set_program_name and program_name.
>>
>> Rationale: This provides the full name of the executable, and discards
>> the "lt-" prefix.
>>
>>   * In library code, or more generally any code that is not near the
>> main() function, use getprogname().
>>
>> Rationale: This makes it possible to put this library code under LGPL
>> and avoid the many linker errors to 'program_name' that people have
>> been seeing.
>
> In consequence, I'm editing NEWS accordingly.
>
>
> 2016-12-17  Bruno Haible  
>
> Un-deprecate the 'getprogname' module.
> * NEWS: Describe the appropriate use-cases of 'progname' versus
> 'getprogname'. Based on discussion summary at
> http://lists.gnu.org/archive/html/bug-gnulib/2016-10/msg00105.html
>
> diff --git a/NEWS b/NEWS
> index 07ca87e..fbbf6f2 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -3,6 +3,16 @@ Important general notes
>
>  DateModules Changes
>
> +2016-09-05  prognameThere is now an alternate module 'getprogname'. 
> It
> +defines a getprogname() function; use it to 
> obtain
> +the name of the current program.
> +Recommended use:
> +- In a program's main() function, and associated
> +  usage() and help() functions, use 'progname'.
> +- In library code, or more generally any code 
> that
> +  is not near the main() function, use
> +  'getprogname'.
> +

Looks good. Thank you, Bruno.

Re: getprogname and libtool

[Bruno Haible]

Followup to this discussion from October 2016:

Jim:
> > I did not mean to imply by that message that we should eliminate every
> > use of the program_name module. My desire is more to avoid accidental
> > use of it when the getprogname module would be more appropriate.

Bruno:
> Fully agree on this.
> 
> The way I currently see it, the two modules serve different purposes
> and it's easy to decide which one to use in which case:
> 
>   * In a program's main() function, and associated usage() and help()
> functions, use set_program_name and program_name.
> 
> Rationale: This provides the full name of the executable, and discards
> the "lt-" prefix.
> 
>   * In library code, or more generally any code that is not near the
> main() function, use getprogname().
> 
> Rationale: This makes it possible to put this library code under LGPL
> and avoid the many linker errors to 'program_name' that people have
> been seeing.

In consequence, I'm editing NEWS accordingly.


2016-12-17  Bruno Haible  

Un-deprecate the 'getprogname' module.
* NEWS: Describe the appropriate use-cases of 'progname' versus
'getprogname'. Based on discussion summary at
http://lists.gnu.org/archive/html/bug-gnulib/2016-10/msg00105.html

diff --git a/NEWS b/NEWS
index 07ca87e..fbbf6f2 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,16 @@ Important general notes
 
 DateModules Changes
 
+2016-09-05  prognameThere is now an alternate module 'getprogname'. It
+defines a getprogname() function; use it to obtain
+the name of the current program.
+Recommended use:
+- In a program's main() function, and associated
+  usage() and help() functions, use 'progname'.
+- In library code, or more generally any code that
+  is not near the main() function, use
+  'getprogname'.
+
 2013-04-24  gettext If your project uses 'gettextize --intl' it is now
 your responsibility to put -I$(top_builddir)/intl
 into the Makefile.am for gnulib.
@@ -37,14 +47,6 @@ DateModules Changes
 2016-11-17  unistr/u32-strmblen   The function u32_strmblen can now return -1.
 2016-11-17  unistr/u32-strmbtouc  The function u32_strmbtouc can now return -1.
 
-2016-09-05  prognameThis module is deprecated.  Please switch to the
-'getprogname' module and its getprogname()
-function to obtain the name of the current program.
-Note that there is no longer any need to export a
-'const char *program_name' variable.
-Currently there is no replacement for
-set_program_name().
-
 2016-08-17  stdbool This no longer supports _Bool for C++.
 Programs intended to be portable to C++
 compilers should use plain 'bool' instead.

Re: getprogname and libtool

[Bruno Haible]

Jim Meyering wrote:
> > +  if (strncmp (p, "lt-", 3) == 0)
> > +p = p + 3;
> 
> Thank you.
> You are welcome to push that, even though I prefer the more concise "p += 3;"

Thanks for the review. Pushed with your suggested edit.

Bruno

Re: getprogname and libtool

[Jim Meyering]

On Tue, Oct 18, 2016 at 3:32 PM, Bruno Haible  wrote:
> Hi Jim,
...
> 2016-10-18  Bruno Haible  
>
> getprogname tests: Avoid failure in packages that use libtool.
> * tests/test-getprogname.c (main): Strip "lt-" prefix.
> Based on a patch by Jim Meyering.
>
> diff --git a/tests/test-getprogname.c b/tests/test-getprogname.c
> index b39ab37..103b58c 100644
> --- a/tests/test-getprogname.c
> +++ b/tests/test-getprogname.c
> @@ -27,6 +27,13 @@ main (void)
>  {
>char const *p = getprogname ();
>
> +  /* libtool creates a temporary executable whose name is sometimes prefixed
> + with "lt-" (depends on the platform).  But the name of the temporary
> + executable is a detail that should not be visible to the end user and to
> + the test suite.  Remove this "lt-" prefix here.  */
> +  if (strncmp (p, "lt-", 3) == 0)
> +p = p + 3;

Thank you.
You are welcome to push that, even though I prefer the more concise "p += 3;"

Re: getprogname and libtool

[Bruno Haible]

Hi Jim,

> > In summary, I like Pino's 'getprogname' module because it nicely solves the
> > problems he listed in
> > http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00048.html.
> >
> > But I disagree with the idea that the 'program_name' module and the
> > set_program_name() function should be deprecated, as expressed in
> > https://lists.gnu.org/archive/html/bug-gnulib/2016-09/msg7.html
> 
> Hi Bruno,
> 
> I did not mean to imply by that message that we should eliminate every
> use of the program_name module. My desire is more to avoid accidental
> use of it when the getprogname module would be more appropriate.

Fully agree on this.

The way I currently see it, the two modules serve different purposes
and it's easy to decide which one to use in which case:

  * In a program's main() function, and associated usage() and help()
functions, use set_program_name and program_name.

Rationale: This provides the full name of the executable, and discards
the "lt-" prefix.

  * In library code, or more generally any code that is not near the
main() function, use getprogname().

Rationale: This makes it possible to put this library code under LGPL
and avoid the many linker errors to 'program_name' that people have
been seeing.

The only remaining problems are:

  1) The test-getprogname failure when added to a package that uses libtool,
 e.g. GNU gettext.
 $ ./test-getprogname
 lt-test-getprogname: test-getprogname.c:29: main: Assertion 
`(__extension__ ...)' failed.

  2) Error messages printed by programs in the source tree (before
 'make install') will show "lt-prog" instead of "prog".

About 1): This can be fixed through a change, below. Proposed.
About 2): This should be fixed in libtool's ltmain.sh. I don't think it's
gnulib's business to override BSD's getprogname() just because of a libtool
quirk.


2016-10-18  Bruno Haible  

getprogname tests: Avoid failure in packages that use libtool.
* tests/test-getprogname.c (main): Strip "lt-" prefix.
Based on a patch by Jim Meyering.

diff --git a/tests/test-getprogname.c b/tests/test-getprogname.c
index b39ab37..103b58c 100644
--- a/tests/test-getprogname.c
+++ b/tests/test-getprogname.c
@@ -27,6 +27,13 @@ main (void)
 {
   char const *p = getprogname ();
 
+  /* libtool creates a temporary executable whose name is sometimes prefixed
+ with "lt-" (depends on the platform).  But the name of the temporary
+ executable is a detail that should not be visible to the end user and to
+ the test suite.  Remove this "lt-" prefix here.  */
+  if (strncmp (p, "lt-", 3) == 0)
+p = p + 3;
+
   /* Note: You can make this test fail
  a) by running it on a case-insensitive file system (such as on Windows,
 Cygwin, or on Mac OS X with a case-insensitive HFS+ file system),

Re: getprogname and libtool

[Jim Meyering]

On Tue, Oct 18, 2016 at 2:29 PM, Bruno Haible  wrote:
> Daiki Ueno wrote:
>> > The consequence is that in packages that use GNU libtool, such programs 
>> > will
>> > print "lt-prog" instead of "prog" in their usage message and other 
>> > messages.
>> > This will disturb
>> >   * the hacker who uses the programs before doing "make install",
>> >   * the test suite.
>>
>> Sorry, I'm skeptical about this.  Would it be useful to test the
>> getprogname functionality from outside of test-getprogname.c?
>
> Here's what I mean: In the GNU gettext package, currently, after having built
> it from source, I can do
>
>   $ cd gettext-tools/src
>   $ ./xgettext --help | head -n 1
>   Aufruf: ./xgettext [OPTION] [EINGABEDATEI]...
>
> When I do the replacements (below) to get rid of the use of the module 
> 'progname',
> I get
>
>   $ cd gettext-tools/src
>   $ ./xgettext --help | head -n 1
>   Aufruf: lt-xgettext [OPTION] [EINGABEDATEI]...
>
> As you can see,
>   - The usage message now doesn't show the path of the executable, only its
> basename. I view this as a regression, because power users often adjust
> PATH and then occasionally by mistake invoke a program from an unintended
> location. (This is reiterating my point 1) from
> https://lists.gnu.org/archive/html/bug-gnulib/2006-01/msg00122.html.)
>   - The basename now starts with "lt-".
>
> In summary, I like Pino's 'getprogname' module because it nicely solves the
> problems he listed in
> http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00048.html.
>
> But I disagree with the idea that the 'program_name' module and the
> set_program_name() function should be deprecated, as expressed in
> https://lists.gnu.org/archive/html/bug-gnulib/2016-09/msg7.html

Hi Bruno,

I did not mean to imply by that message that we should eliminate every
use of the program_name module. My desire is more to avoid accidental
use of it when the getprogname module would be more appropriate.

Re: getprogname and libtool

[Bruno Haible]

Daiki Ueno wrote:
> > The consequence is that in packages that use GNU libtool, such programs will
> > print "lt-prog" instead of "prog" in their usage message and other messages.
> > This will disturb
> >   * the hacker who uses the programs before doing "make install",
> >   * the test suite.
> 
> Sorry, I'm skeptical about this.  Would it be useful to test the
> getprogname functionality from outside of test-getprogname.c?

Here's what I mean: In the GNU gettext package, currently, after having built
it from source, I can do

  $ cd gettext-tools/src
  $ ./xgettext --help | head -n 1
  Aufruf: ./xgettext [OPTION] [EINGABEDATEI]...

When I do the replacements (below) to get rid of the use of the module 
'progname',
I get

  $ cd gettext-tools/src
  $ ./xgettext --help | head -n 1
  Aufruf: lt-xgettext [OPTION] [EINGABEDATEI]...

As you can see,
  - The usage message now doesn't show the path of the executable, only its
basename. I view this as a regression, because power users often adjust
PATH and then occasionally by mistake invoke a program from an unintended
location. (This is reiterating my point 1) from
https://lists.gnu.org/archive/html/bug-gnulib/2006-01/msg00122.html.)
  - The basename now starts with "lt-".

In summary, I like Pino's 'getprogname' module because it nicely solves the
problems he listed in
http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00048.html.

But I disagree with the idea that the 'program_name' module and the
set_program_name() function should be deprecated, as expressed in
https://lists.gnu.org/archive/html/bug-gnulib/2016-09/msg7.html

Bruno


diff --git a/gettext-tools/src/xgettext.c b/gettext-tools/src/xgettext.c
index f848d76..4075caa 100644
--- a/gettext-tools/src/xgettext.c
+++ b/gettext-tools/src/xgettext.c
@@ -39,7 +39,7 @@
 #include "str-list.h"
 #include "error.h"
 #include "error-progname.h"
-#include "progname.h"
+#include "getprogname.h"
 #include "relocatable.h"
 #include "basename.h"
 #include "xerror.h"
@@ -342,7 +342,6 @@ main (int argc, char *argv[])
   size_t i;
 
   /* Set program name for messages.  */
-  set_program_name (argv[0]);
   error_print_progname = maybe_print_progname;
 
 #ifdef HAVE_SETLOCALE
@@ -676,7 +675,7 @@ main (int argc, char *argv[])
   /* Version information requested.  */
   if (do_version)
 {
-  printf ("%s (GNU %s) %s\n", basename (program_name), PACKAGE, VERSION);
+  printf ("%s (GNU %s) %s\n", getprogname (), PACKAGE, VERSION);
   /* xgettext: no-wrap */
   printf (_("Copyright (C) %s Free Software Foundation, Inc.\n\
 License GPLv3+: GNU GPL version 3 or later 
\n\
@@ -801,14 +800,14 @@ xgettext cannot work without keywords to look for"));
 Cannot convert from \"%s\" to \"%s\". %s relies on iconv(), \
 and iconv() does not support this conversion."),
xgettext_global_source_encoding, po_charset_utf8,
-   basename (program_name));
+   getprogname ());
   xgettext_global_source_iconv = cd;
 #else
   error (EXIT_FAILURE, 0, _("\
 Cannot convert from \"%s\" to \"%s\". %s relies on iconv(). \
 This version was built without iconv()."),
  xgettext_global_source_encoding, po_charset_utf8,
- basename (program_name));
+ getprogname ());
 #endif
 }
 
@@ -1030,12 +1029,12 @@ usage (int status)
 {
   if (status != EXIT_SUCCESS)
 fprintf (stderr, _("Try '%s --help' for more information.\n"),
- program_name);
+ getprogname ());
   else
 {
   printf (_("\
 Usage: %s [OPTION] [INPUTFILE]...\n\
-"), program_name);
+"), getprogname ());
   printf ("\n");
   printf (_("\
 Extract translatable strings from given input files.\n\

Re: getprogname and libtool

[Jim Meyering]

On Tue, Oct 18, 2016 at 12:07 PM, Daiki Ueno  wrote:
> Bruno Haible  writes:
>
>> The consequence is that in packages that use GNU libtool, such programs will
>> print "lt-prog" instead of "prog" in their usage message and other messages.
>> This will disturb
>>   * the hacker who uses the programs before doing "make install",
>>   * the test suite.
>
> Sorry, I'm skeptical about this.  Would it be useful to test the
> getprogname functionality from outside of test-getprogname.c?
>
>> What are the possible solutions? I can see these:
>>   a) Modify the 'getprogname' module to strip a leading 'lt-' prefix
>>  (even on BSD and Cygwin platforms).
>>   b) Create a distinct module that is like 'getprogname' but also strips the
>>  'lt-' prefix, and change the recommended idiom accordingly.
>>   c) Modify libtool to store the executables as .libs/lt/prog${EXEEXT} rather
>>  than .libs/lt-prog${EXEEXT}.
>
> I would vote for (b), but how about just creating a shell script wrapper
> around test-getprogname, which checks if it is a libtool wrapper or a
> native binary and somehow passes the real program name?

I have not thought about this enough, and will probably end up
discarding or reworking the patch I have just posted.

Re: getprogname and libtool

[Daiki Ueno]

Bruno Haible  writes:

> The consequence is that in packages that use GNU libtool, such programs will
> print "lt-prog" instead of "prog" in their usage message and other messages.
> This will disturb
>   * the hacker who uses the programs before doing "make install",
>   * the test suite.

Sorry, I'm skeptical about this.  Would it be useful to test the
getprogname functionality from outside of test-getprogname.c?

> What are the possible solutions? I can see these:
>   a) Modify the 'getprogname' module to strip a leading 'lt-' prefix
>  (even on BSD and Cygwin platforms).
>   b) Create a distinct module that is like 'getprogname' but also strips the
>  'lt-' prefix, and change the recommended idiom accordingly.
>   c) Modify libtool to store the executables as .libs/lt/prog${EXEEXT} rather
>  than .libs/lt-prog${EXEEXT}.

I would vote for (b), but how about just creating a shell script wrapper
around test-getprogname, which checks if it is a libtool wrapper or a
native binary and somehow passes the real program name?

Regards,
-- 
Daiki Ueno