Discussion:
getprogname: comments and test failure on Cygwin
(too old to reply)
Bruno Haible
2016-10-16 11:55:18 UTC
Permalink
Raw Message
Hi,

The 'getprogname' module test fails on Cygwin 2.6, because the returned
value is "test-getprogname", not "test-getprogname.exe". (On mingw, on the
other hand, it really is "test-getprogname.exe".)

Also, while at it, I'd like to add comments:
1. The declaration in getprogname.h does not state what the function does
or return.
2. In getprogname.c it is hard to understand which code is used for which
platform.
3. In test-getprogname.c there is no explanation why the file name is compared
with strcmp and not strcasecmp.

Here's a proposed patch.

Bruno


2016-10-16 Bruno Haible <***@clisp.org>

getprogname: Fix test failure on Cygwin. Comments.
* lib/getprogname.h: Add comments.
* lib/getprogname.c: Add comments. Fix #elif indentation.
* tests/test-getprogname.c (main): On Cygwin, expect a result without
".exe" suffix.

diff --git a/lib/getprogname.h b/lib/getprogname.h
index 36b8ba8..559b1f2 100644
--- a/lib/getprogname.h
+++ b/lib/getprogname.h
@@ -23,6 +23,8 @@
extern "C" {
#endif

+/* Return the base name of the executing program.
+ On native Windows this will usually end in ".exe" or ".EXE". */
#ifndef HAVE_GETPROGNAME
extern char const *getprogname (void)
# ifdef HAVE_DECL_PROGRAM_INVOCATION_NAME
diff --git a/lib/getprogname.c b/lib/getprogname.c
index 0e8d963..ec2c948 100644
--- a/lib/getprogname.c
+++ b/lib/getprogname.c
@@ -38,24 +38,29 @@

#include "dirname.h"

-#ifndef HAVE_GETPROGNAME
-
+#ifndef HAVE_GETPROGNAME /* not Mac OS X, FreeBSD, NetBSD, OpenBSD >= 5.4, Cygwin */
char const *
getprogname (void)
-{
-# if HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME
+{Minix 3.1.8, IRIX 6.5, OSF/1 5.1, Interix 3.5.
+# if HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME /* glibc, BeOS */
+ /* https://www.gnu.org/software/libc/manual/html_node/Error-Messages.html */
return program_invocation_short_name;
-# elif HAVE_DECL_PROGRAM_INVOCATION_NAME
+# elif HAVE_DECL_PROGRAM_INVOCATION_NAME /* glibc, BeOS */
+ /* https://www.gnu.org/software/libc/manual/html_node/Error-Messages.html */
return last_component (program_invocation_name);
-# elif HAVE_GETEXECNAME
+# elif HAVE_GETEXECNAME /* Solaris */
+ /* http://docs.oracle.com/cd/E19253-01/816-5168/6mbb3hrb1/index.html */
const char *p = getexecname ();
if (!p)
p = "?";
return last_component (p);
-# elif HAVE_DECL___ARGV
+# elif HAVE_DECL___ARGV /* mingw, MSVC */
+ /* https://msdn.microsoft.com/en-us/library/dn727674.aspx */
const char *p = __argv && __argv[0] ? __argv[0] : "?";
return last_component (p);
-# elif HAVE_VAR___PROGNAME
+# elif HAVE_VAR___PROGNAME /* OpenBSD, QNX */
+ /* http://man.openbsd.org/style.9 */
+ /* http://www.qnx.de/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.neutrino_lib_ref%2Fp%2F__progname.html */
/* Be careful to declare this only when we absolutely need it
(OpenBSD 5.1), rather than when it's available. Otherwise,
its mere declaration makes program_invocation_short_name
@@ -63,8 +68,8 @@ getprogname (void)
extern char *__progname;
const char *p = __progname;
return p && p[0] ? p : "?";
-# elif _AIX
- /* Idea by Bastien ROUCARIÈS <***@hidden>,
+# elif _AIX /* AIX */
+ /* Idea by Bastien ROUCARIÈS,
http://lists.gnu.org/archive/html/bug-gnulib/2010-12/msg00095.html
Reference: http://
ibm.biz/knowctr#ssw_aix_53/com.ibm.aix.basetechref/doc/basetrf1/getprocs.htm
@@ -83,7 +88,7 @@ getprogname (void)
p = "?";
}
return p;
-#elif __MVS__
+# elif __MVS__ /* z/OS */
/* https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/rtwgetp.htm */
static char *p = "?";
static int first = 1;
diff --git a/tests/test-getprogname.c b/tests/test-getprogname.c
index 6e3f694..b39ab37 100644
--- a/tests/test-getprogname.c
+++ b/tests/test-getprogname.c
@@ -26,6 +26,22 @@ int
main (void)
{
char const *p = getprogname ();
+
+ /* 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),
+ with an invocation that contains upper case characters, e.g.
+ test-GETPROGNAME,
+ b) by hardlinking or symlinking it to a different name (e.g. test-foo)
+ and invoking it through that name.
+ That's not the intended use. The Makefile always invokes it as
+ 'test-getprogname${EXEEXT}'. */
+#if defined __CYGWIN__
+ /* The Cygwin getprogname() function strips the ".exe" suffix. */
+ assert (STREQ (p, "test-getprogname"));
+#else
assert (STREQ (p, "test-getprogname" EXEEXT));
+#endif
+
return 0;
}
Pádraig Brady
2016-10-16 12:15:18 UTC
Permalink
Raw Message
Post by Bruno Haible
Hi,
The 'getprogname' module test fails on Cygwin 2.6, because the returned
value is "test-getprogname", not "test-getprogname.exe". (On mingw, on the
other hand, it really is "test-getprogname.exe".)
1. The declaration in getprogname.h does not state what the function does
or return.
2. In getprogname.c it is hard to understand which code is used for which
platform.
3. In test-getprogname.c there is no explanation why the file name is compared
with strcmp and not strcasecmp.
All improvements look good to me.

thanks,
Pádraig.
Jim Meyering
2016-10-16 14:56:37 UTC
Permalink
Raw Message
Post by Pádraig Brady
Post by Bruno Haible
Hi,
The 'getprogname' module test fails on Cygwin 2.6, because the returned
value is "test-getprogname", not "test-getprogname.exe". (On mingw, on the
other hand, it really is "test-getprogname.exe".)
1. The declaration in getprogname.h does not state what the function does
or return.
2. In getprogname.c it is hard to understand which code is used for which
platform.
3. In test-getprogname.c there is no explanation why the file name is compared
with strcmp and not strcasecmp.
All improvements look good to me.
Likewise.
Thank you!
Daiki Ueno
2016-10-18 13:07:22 UTC
Permalink
Raw Message
Hello,
Post by Bruno Haible
Hi,
The 'getprogname' module test fails on Cygwin 2.6, because the returned
value is "test-getprogname", not "test-getprogname.exe". (On mingw, on the
other hand, it really is "test-getprogname.exe".)
On a related note, this new test also fails when it is invoked as a
libtool wrapper script, because of the "lt-" prefix.

$ ./gnulib-tool --create-testdir --dir t --libtool getprogname
$ cd t && ./configure
$ sed -i 's/^noinst_LTLIBRARIES +=/lib_LTLIBRARIES =/' gllib/Makefile.am
$ make && make check

FAIL: test-getprogname
======================

lt-test-getprogname: test-getprogname.c:29: main: Assertion `STREQ (p, "test-getprogname" EXEEXT)' failed.
FAIL test-getprogname (exit status: 134)

Sorry for not providing a patch. I have no idea how to conditionalize
this in the test program itself.

Regards,
--
Daiki Ueno
Bruno Haible
2016-10-18 14:26:17 UTC
Permalink
Raw Message
Post by Daiki Ueno
On a related note, this new test also fails when it is invoked as a
libtool wrapper script, because of the "lt-" prefix.
$ ./gnulib-tool --create-testdir --dir t --libtool getprogname
$ cd t && ./configure
$ sed -i 's/^noinst_LTLIBRARIES +=/lib_LTLIBRARIES =/' gllib/Makefile.am
$ make && make check
FAIL: test-getprogname
======================
lt-test-getprogname: test-getprogname.c:29: main: Assertion `STREQ (p, "test-getprogname" EXEEXT)' failed.
FAIL test-getprogname (exit status: 134)
This is not only a problem with the test. It's a problem with the deprecation
of the 'progname' module.

Previously, GNU gettext and other packages were using the idiom

int
main (int argc, char **argv)
{
set_program_name (argv[0]);
...
if (...)
{
printf (_("Usage: %s [OPTION] ARGUMENT...), program_name);
...
}
...
}

Now, the recommended idiom is

int
main (int argc, char **argv)
{
...
if (...)
{
printf (_("Usage: %s [OPTION] ARGUMENT...), getprogname ());
...
}
...
}

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.

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}.

Bruno
--
Im memoriam Gisi Fleischmann <http://en.wikipedia.org/wiki/Gisi_Fleischmann>
Daiki Ueno
2016-10-18 19:07:01 UTC
Permalink
Raw Message
Post by Bruno Haible
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?
Post by Bruno Haible
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
Jim Meyering
2016-10-18 19:16:33 UTC
Permalink
Raw Message
Post by Daiki Ueno
Post by Bruno Haible
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?
Post by Bruno Haible
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.
Bruno Haible
2016-10-18 21:29:50 UTC
Permalink
Raw Message
Post by Daiki Ueno
Post by Bruno Haible
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/msg00007.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 <http://gnu.org/licenses/gpl.html>\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\
Jim Meyering
2016-10-18 21:57:36 UTC
Permalink
Raw Message
Post by Bruno Haible
Post by Daiki Ueno
Post by Bruno Haible
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/msg00007.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.
Bruno Haible
2016-10-18 22:32:28 UTC
Permalink
Raw Message
Hi Jim,
Post by Jim Meyering
Post by Bruno Haible
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/msg00007.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 <***@clisp.org>

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),
Jim Meyering
2016-10-18 23:29:07 UTC
Permalink
Raw Message
Post by Bruno Haible
Hi Jim,
...
Post by 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;"
Bruno Haible
2016-10-19 01:04:49 UTC
Permalink
Raw Message
Post by Jim Meyering
Post by Bruno Haible
+ 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
Bruno Haible
2016-12-17 23:27:36 UTC
Permalink
Raw Message
Post by Bruno Haible
Post by Jim Meyering
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
* 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 <***@clisp.org>

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

Date Modules Changes

+2016-09-05 progname There 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 @@ Date Modules 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 progname This 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.
Jim Meyering
2016-12-18 10:23:38 UTC
Permalink
Raw Message
Post by Bruno Haible
Post by Bruno Haible
Post by Jim Meyering
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
* 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.
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
Date Modules Changes
+2016-09-05 progname There is now an alternate module 'getprogname'. It
+ defines a getprogname() function; use it to obtain
+ the name of the current program.
+ - 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.

Jim Meyering
2016-10-18 19:14:25 UTC
Permalink
Raw Message
Post by Daiki Ueno
Hello,
Post by Bruno Haible
Hi,
The 'getprogname' module test fails on Cygwin 2.6, because the returned
value is "test-getprogname", not "test-getprogname.exe". (On mingw, on the
other hand, it really is "test-getprogname.exe".)
On a related note, this new test also fails when it is invoked as a
libtool wrapper script, because of the "lt-" prefix.
$ ./gnulib-tool --create-testdir --dir t --libtool getprogname
$ cd t && ./configure
$ sed -i 's/^noinst_LTLIBRARIES +=/lib_LTLIBRARIES =/' gllib/Makefile.am
$ make && make check
FAIL: test-getprogname
======================
lt-test-getprogname: test-getprogname.c:29: main: Assertion `STREQ (p, "test-getprogname" EXEEXT)' failed.
FAIL test-getprogname (exit status: 134)
Sorry for not providing a patch. I have no idea how to conditionalize
this in the test program itself.
Thank you both.
Here is a proposed patch:
Bruno Haible
2016-10-18 22:11:47 UTC
Permalink
Raw Message
Post by Jim Meyering
Post by Pádraig Brady
All improvements look good to me.
Likewise.
OK, I pushed it.
Loading...