Re: getprogname: Move declaration from "getprogname.h" to

On 1/21/23 18:10, Bruno Haible wrote: I don't understand. Is the #warning that I added misleading? No, all I meant was that if I see the warning I do the same thing that I do if I see the error from the missing #include, so there's not much point in having a transition period with the

Re: getprogname: Move declaration from "getprogname.h" to

Paul Eggert wrote: > I ... wouldn't object to a very short transition period Short transition periods tend to cause unnecessary hassle to some users. I therefore favour 1 year or 2 years as a transition period. > since the current #warning is something I would treat > like a diagnostic that

Re: getprogname: Move declaration from "getprogname.h" to

On 1/21/23 02:56, Bruno Haible wrote: For a transition period, "getprogname.h" can continue to exist, but will emit a deprecation warning. Thanks for doing all that. I've removed "#include " from the programs I help maintain, and wouldn't object to a very short transition period since the

getprogname: Move declaration from "getprogname.h" to

Why is the getprogname() function declared in "getprogname.h"? All platforms that have this function — Mac OS X, FreeBSD, NetBSD, OpenBSD >= 5.4, Solaris >= 11, Cygwin, Android API level >= 21 — declare it in . It thus appears very unlikely that, if glibc ever adds this f

Re: getprogname fails randomly on PA-RISC HPUX 11.11 with 64-bit kernel

s are correct in the smaller struct? I don't know whether the problem is CPU type or HP-UX version.  If the code depends on CPU type, that would mean binaries would not be forward compatible. I checked the offsets.  They are correct. > > Not being sure, it would be more maintainable to move

Re: getprogname fails randomly on PA-RISC HPUX 11.11 with 64-bit kernel

atus64 + 288; Are you sure the struct size depends on the CPU type, not on the HP-UX version? (I don't remember whether I tested this on both HPPA and IA64 hardware.) And are you sure the offsets are correct in the smaller struct? Not being sure, it would be more maintainable to move this code into a sep

getprogname fails randomly on PA-RISC HPUX 11.11 with 64-bit kernel

The test suites of applications using getprogname to print the current process name sometimes fails and prints '?' when both the pstat_getproc and __pstat_getproc64 fail. pstat_getproc never fails when I define _PSTAT64. Eventually, I found that the call to __pstat_getproc64 is sensitive

Re: Fwd: Port getprogname module to Tru64

Thanks, I installed that in your name.

Re: Fwd: Port getprogname module to Tru64

On 2021-05-22 10:52, Bruno Haible wrote: > This patch was mangled by your mailer. Please send patches as attachments > to the mail, not inline in the mail. > > Bruno > Sure. I've attached the patch, which is working in my testing. Larkin --- a/lib/getprogname.c 2021-05-22

Re: Fwd: Port getprogname module to Tru64

Hi, Larkin Nickle wrote: > > This patch allows getprogname to work under Tru64. This has been tested > > on Tru64 5.1B-6 with success. Tru64 is unsupported by gnulib, see <https://www.gnu.org/software/gnulib/manual/html_node/Formerly-Supported-Platforms.html> If you provide

Re: Fwd: Port getprogname module to Tru64

On 2021-05-22 02:40, Larkin Nickle wrote: This patch allows getprogname to work under Tru64. This has been tested on Tru64 5.1B-6 with success. Larkin ... Oops, the last patch has a bad header. This should be fixed. :) Larkin --- a/lib/getprogname.c 2021-05-22 02:27:02.835632500

Fwd: Port getprogname module to Tru64

This patch allows getprogname to work under Tru64. This has been tested on Tru64 5.1B-6 with success. Larkin --- lib/getprogname.c 2021-05-22 02:27:02.835632500 -0400 +++ lib/getprogname.c.patched 2021-05-22 02:33:55.003154200 -0400 @@ -43,7 +43,7 @@ # include #endif -#ifdef __sgi

Re: error, getprogname: Relicense under LGPLv2+

Thank you all for the very quick approval! Done: 2021-03-22 Bruno Haible getprogname: Relicense under LGPLv2+. Pino Toscano's approval is in <https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00109.html>. Paul Eggert's approval is in

Re: Fwd: error, getprogname: Relicense under LGPLv2+

Bruno Haible wrote: For lib/getprogname.c we would need the approval of Pino Toscano Paul Eggert Jim Meyering Gisle Vanem Daniel Richard G John David Anglin Benji Wiebe No problem. Go ahead.

Re: error, getprogname: Relicense under LGPLv2+

Yes I give permission to relicense my code as requested. On 3/22/21 8:08 AM, Bruno Haible wrote: I would like to use the module 'clean-temp' and, with it, the modules 'error' and 'getprogname' in a library under GPLv2+ (namely, GNU libffcall) and in a gnulib module for JIT support

Re: error, getprogname: Relicense under LGPLv2+

Hi Bruno, hello list, On Mon, 2021 Mar 22 09:08-04:00, Bruno Haible wrote: > I would like to use the module 'clean-temp' and, with it, the modules 'error' > and 'getprogname' in a library under GPLv2+ (namely, GNU libffcall) and in a > gnulib module for JIT support. > > To this

Re: error, getprogname: Relicense under LGPLv2+

On Monday, 22 March 2021 16:28:57 CET John David Anglin wrote: > On 2021-03-22 10:37 a.m., Jim Meyering wrote: > > On Mon, Mar 22, 2021 at 6:09 AM Bruno Haible wrote: > >> I would like to use the module 'clean-temp' and, with it, the modules > >> 'error' > >>

Re: error, getprogname: Relicense under LGPLv2+

On 3/22/21 6:08 AM, Bruno Haible wrote: To give your approval, please reply with the mailing list in CC. Sounds good to me.

Re: error, getprogname: Relicense under LGPLv2+

On 2021-03-22 10:37 a.m., Jim Meyering wrote: > On Mon, Mar 22, 2021 at 6:09 AM Bruno Haible wrote: >> I would like to use the module 'clean-temp' and, with it, the modules 'error' >> and 'getprogname' in a library under GPLv2+ (namely, GNU libffcall) and in a >> gnulib m

Re: error, getprogname: Relicense under LGPLv2+

On Mon, Mar 22, 2021 at 6:09 AM Bruno Haible wrote: > I would like to use the module 'clean-temp' and, with it, the modules 'error' > and 'getprogname' in a library under GPLv2+ (namely, GNU libffcall) and in a > gnulib module for JIT support. > > To this effect, I would like

error, getprogname: Relicense under LGPLv2+

I would like to use the module 'clean-temp' and, with it, the modules 'error' and 'getprogname' in a library under GPLv2+ (namely, GNU libffcall) and in a gnulib module for JIT support. To this effect, I would like to ask for your permission to relicense these modules (error and getprogname) from

argp: Don't break getprogname on non-glibc systems

In a testdir of all of gnulib, 'test-getprogname' crashes on Alpine Linux 3.12. The cause is that the 'argp' module defines program_invocation_short_name as a global variable, outside libc, and therefore libc cannot initialize it. This patch fixes it. 2020-11-22 Bruno Haible argp

Re: Port getprogname module to SCO OpenServer

Hi Benji, > > It is better, but there are still (minor) things to tweak. > Minor things tweaked. > > I'm not sure why I cast getpid to int. > > Including string.h did fix the strrchr warning. > > Now using __SCO_SERVER__ || __sysv5__ for OpenServer6/UnixWare7 and SCO > cc/GCC detection.

Re: Port getprogname module to SCO OpenServer

= 5.4, Cygwin */ @@ -245,6 +251,38 @@ getprogname (void) } } return NULL; +# elif defined __SCO_VERSION__ || defined __sysv5__/* SCO OpenServer6/UnixWare */ + char buf[80]; + int fd; + sprintf (buf, "/proc/%d/cmdline", getpid()); + fd = open (buf, O_

Re: Port getprogname module to SCO OpenServer

On Wed, 7 Oct 2020, Bruno Haible wrote: > I hope the main conclusions from the table [1] stand? Yes. > Bruno > > [1] https://lists.gnu.org/archive/html/bug-gnulib/2020-10/msg00022.html > -- Tim RiceMultitalents t...@multitalents.net

Re: Port getprogname module to SCO OpenServer

Tim Rice wrote: > > out, namely that *none* of the 6 compilers that he tested defines both > > __USLC__ and __SCO_VERSION__. > > Actually the table *does* show __USLC__ and __SCO_VERSION__ defined > in the native compiler for both Openserver 6 and UnixWare 7. Oops, you are right. Seems I have

Re: Port getprogname module to SCO OpenServer

On Tue, 6 Oct 2020, Bruno Haible wrote: > Benji Wiebe wrote: > > http://osr600doc.sco.com/en/man/html.CP/cc.CP.html#cc_preassertion > > > > Is where the predefined constants for the builtin cc are listed. > > Thanks. You will notice that this web page says that both __USLC__ and >

Re: Port getprogname module to SCO OpenServer

Hi Tim, > > OK. And what about __UNIXWARE__ and __OPENSERVER__ that I see being used > > [1]? > > On which versions are they defined? > > For the most part __UNIXWARE__ and __OPENSERVER__ were used by some in > build driver scripts. Usually like CFLAGS="-O -D__UNIXWARE__" Since you say "by

Re: Port getprogname module to SCO OpenServer

Benji Wiebe wrote: > http://osr600doc.sco.com/en/man/html.CP/cc.CP.html#cc_preassertion > > Is where the predefined constants for the builtin cc are listed. Thanks. You will notice that this web page says that both __USLC__ and __SCO_VERSION__ are defined. Which contradicts what Tim Rice just

Re: Port getprogname module to SCO OpenServer

On Mon, 5 Oct 2020, Benji Wiebe wrote: > http://osr600doc.sco.com/en/man/html.CP/cc.CP.html#cc_preassertion For completeness http://uw714doc.xinuos.com/en/man/html.1/cc.1.html http://osr507doc.xinuos.com/cgi-bin/man?mansearchword=cc==en > Is where the predefined constants for the builtin cc are

Re: Port getprogname module to SCO OpenServer

http://osr600doc.sco.com/en/man/html.CP/cc.CP.html#cc_preassertion Is where the predefined constants for the builtin cc are listed. Do we need to support a possible future port of clang to SCO OpenServer when OpenServer is dead? Or just make it work with the current compilers available?

Re: Port getprogname module to SCO OpenServer

On Sun, 4 Oct 2020, Bruno Haible wrote: > OK. And what about __UNIXWARE__ and __OPENSERVER__ that I see being used [1]? > On which versions are they defined? For the most part __UNIXWARE__ and __OPENSERVER__ were used by some in build driver scripts. Usually like CFLAGS="-O -D__UNIXWARE__" As

Re: Port getprogname module to SCO OpenServer

Tim Rice wrote: > > Hi Bruno, > > On Sat, 3 Oct 2020, Bruno Haible wrote: > > > Tim Rice wrote: > > > > +# elif defined __SCO_VERSION__ /* SCO OpenServer/UnixWare */ > > > > > > While __SCO_VERSION__ covers Openserver 6 and UnixWare 7, > > > what is normally used for 6 and 7 is __USLC__ for

Re: Port getprogname module to SCO OpenServer

Hi Bruno, On Sat, 3 Oct 2020, Bruno Haible wrote: > Tim Rice wrote: > > > +# elif defined __SCO_VERSION__ /* SCO OpenServer/UnixWare */ > > > > While __SCO_VERSION__ covers Openserver 6 and UnixWare 7, > > what is normally used for 6 and 7 is __USLC__ for the native compiler > > and

Re: Port getprogname module to SCO OpenServer

hat you use strrchr(), you need to also #include here. > +#endif > + > #include "basename-lgpl.h" > > #ifndef HAVE_GETPROGNAME /* not Mac OS X, FreeBSD, NetBSD, > OpenBSD >= 5.4, Cygwin */ > @@ -245,6 +250,38 @@ getprogname (void) >

Re: Port getprogname module to SCO OpenServer

Tim Rice wrote: > > +# elif defined __SCO_VERSION__ /* SCO OpenServer/UnixWare */ > > While __SCO_VERSION__ covers Openserver 6 and UnixWare 7, > what is normally used for 6 and 7 is __USLC__ for the native compiler > and __sysv5__ for gcc > > Ie. > # elif defined __USLC__ || defined __sysv5__

Re: Port getprogname module to SCO OpenServer

Oh and I forgot to mention, the cast from strrchr is needed to silence a warning from SCO's CC: UX:acomp: WARNING: "gpn_test.c", line 16: improper pointer/integer combination: op "="

Re: Port getprogname module to SCO OpenServer

Hi Benji, On Wed, 30 Sep 2020, Benji Wiebe wrote: > I ported the getprogname module to SCO OpenServer 6 (should also work on OSR5 > and UnixWare). It prevents several OSS packages from building. No proc filesystem on Openserver 5 so it will not work there. Would need a different &

Re: Port getprogname module to SCO OpenServer

Hi Benji, > I just made it read from /proc//cmdline to get the command name. > The patch is below. Comments are welcome. Thanks! Thanks for the patch. I have a couple of improvement suggestions, though: > + char buf[50]; > + char *ret; > + int fd; > + int pathlen; Can you try to minimize

Port getprogname module to SCO OpenServer

I ported the getprogname module to SCO OpenServer 6 (should also work on OSR5 and UnixWare). It prevents several OSS packages from building. I just made it read from /proc//cmdline to get the command name. The patch is below. Comments are welcome. Thanks! -Benji diff --git a/lib

getprogname: Port to Android 4.3

On Android 4.3, this test fails: FAIL: test-getprogname == FAIL test-getprogname (exit status: 139) The reason is that __progname contains the full argv[0], not just the last component of it (like on OpenBSD). This patch fixes it. 2019-01-25 Bruno Haible

getprogname: support for 32-bit programs on HP-UX

2018-10-11 Bruno Haible getprogname: Add support for 32-bit programs on HP-UX. * lib/getprogname.c (getprogname) [HP-UX]: If pstat_getproc fails, try the similar functions 32-bit programs on 64-bit HP-UX. diff --git a/lib/getprogname.c b/lib/getprogname.c index 4f97df4

getprogname: improvement on HP-UX

is a truncation of the program name to 14 characters. This can be avoided in some cases. The command can be up to 63 characters and may contain the program name. 2018-10-11 Bruno Haible getprogname: Work around program name truncation when possible. * lib/getprogname.c

Re: [PATCH] getprogname: fix port to IRIX

Thanks for fixing that longstanding typo. But wow, IRIX? SGI itself stopped supporting IRIX in 2013. Do you have a computer museum in your attic? In the late 1980s I unwisely accepted an old PDP-11 that rested in my garage until I threw it away. I had been thinking of running 7th Edition Unix

Re: [PATCH] getprogname: fix port to IRIX

n the compilation of "../../lib/getprogname.c". This patch fixes it. 2017-11-11 Bruno Haible <br...@clisp.org> getprogname: Fix compilation error on IRIX. * lib/getprogname.c (getprogname) [__sgi]: Fix type of local variable 'namesize'. diff --git a/l

[PATCH] getprogname: fix port to IRIX

* lib/getprogname.c (getprogname) [__sgi]: Don't dump core if malloc returns NULL. --- ChangeLog | 4 lib/getprogname.c | 7 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 79475df..0d60422 100644 --- a/ChangeLog +++ b/ChangeLog

Re: getprogname and libtool

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: &

Re: getprogname and libtool

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

Re: getprogname and libtool

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

On Tue, Oct 18, 2016 at 3:32 PM, Bruno Haible <br...@clisp.org> wrote: > Hi Jim, ... > 2016-10-18 Bruno Haible <br...@clisp.org> > > getprogname tests: Avoid failure in packages that use libtool. > * tests/test-getprogname.c (main): Strip "lt-&quo

Re: getprogname and libtool

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 &

Re: getprogname: comments and test failure on Cygwin

Padraig Brady and Jim Meyering wrote: > > All improvements look good to me. > > Likewise. OK, I pushed it.

Re: getprogname and libtool

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 funct

Re: getprogname and libtool

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,

Re: getprogname and libtool

e 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 te

Re: getprogname: comments and test failure on Cygwin

On Tue, Oct 18, 2016 at 6:07 AM, Daiki Ueno <u...@gnu.org> wrote: > Hello, > > Jim Meyering <j...@meyering.net> writes: > >> On Sun, Oct 16, 2016 at 5:15 AM, Pádraig Brady <p...@draigbrady.com> wrote: >>> On 16/10/16 12:55, Bruno Haible wrote: >>&

Re: getprogname and libtool

he 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 st

getprogname and libtool

Daiki Ueno wrote: > 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_LTLI

Re: getprogname: comments and test failure on Cygwin

Hello, Jim Meyering <j...@meyering.net> writes: > On Sun, Oct 16, 2016 at 5:15 AM, Pádraig Brady <p...@draigbrady.com> wrote: >> On 16/10/16 12:55, Bruno Haible wrote: >>> Hi, >>> >>> The 'getprogname' module test fails on Cygwin 2.6, bec

Re: getprogname: comments and test failure on Cygwin

On Sun, Oct 16, 2016 at 5:15 AM, Pádraig Brady <p...@draigbrady.com> wrote: > On 16/10/16 12:55, Bruno Haible wrote: >> Hi, >> >> The 'getprogname' module test fails on Cygwin 2.6, because the returned >> value is "test-getprogname", not "test-g

Re: getprogname: comments and test failure on Cygwin

On 16/10/16 12:55, Bruno Haible wrote: > 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&qu

getprogname: comments and test failure on Cygwin

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 i

Re: getprogname() for IBM z/OS

>> >>> Revised patch is tested and attached. >> >> Pushed at: >> http://git.svh.gnu.org/gitweb/?p=gnulib.git;a=commit;h=d75cbb3 > > Thanks. > This will be pulled into grep soon. I've pushed this additional fix: From 7dad5f25591de682c452c3fc39ffe2fa11e21491

Re: getprogname() for IBM z/OS

On Thu, Oct 13, 2016 at 1:50 AM, Pádraig Brady wrote: > On 13/10/16 02:43, Daniel Richard G. wrote: >> On Wed, 2016 Oct 12 11:04+0100, Pádraig Brady wrote: >>> >>> You only want to strdup once. >>> So you could use a static to track that as is done in the AIX case. >> >> Ah,

Re: getprogname() for IBM z/OS

On 13/10/16 02:43, Daniel Richard G. wrote: > On Wed, 2016 Oct 12 11:04+0100, Pádraig Brady wrote: >> >> You only want to strdup once. >> So you could use a static to track that as is done in the AIX case. > > Ah, I see, the program name never changes. > >> You can call free(NULL), so the last 3

Re: getprogname() for IBM z/OS

fdef __MVS__ +# ifndef _OPEN_SYS +# define _OPEN_SYS +# endif +# include +# include +#endif + #include "dirname.h" #ifndef HAVE_GETPROGNAME @@ -75,6 +83,37 @@ getprogname (void) p = "?"; } return p; +#elif __MVS__ + /* https://www.ibm.com/supp

Re: getprogname() for IBM z/OS

On 12/10/16 09:51, Daniel Richard G. wrote: > +#elif __MVS__ > + /* > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/rtwgetp.htm > */ > + char *p = "?"; > + pid_t pid = getpid (); > + int token; > + W_PSPROC buf; > + memset (, 0, sizeof(buf)); > +

getprogname() for IBM z/OS

Please double-check the use of strdup(), to avoid memory leakage. 2016-10-12 Daniel Richard G. <sk...@iskunk.org> getprogname: port to IBM z/OS * lib/getprogname.c (getprogname) [__MVS__]: Use getpid, w_getpsent and strdup to obtain the program name string. --

Re: [PATCH] getprogname: port to OpenBSD 5.1

On Wed, Sep 28, 2016 at 11:28 AM, Jim Meyering <j...@meyering.net> wrote: > FYI: grep (due to its use of the new getprogname module) would fail to > configure on OpenBSD 5.1. I'll soon push this to gnulib and then > update grep's gnulib submodule to latest to pull it in. Glad I t

[PATCH] getprogname: port to OpenBSD 5.1

FYI: grep (due to its use of the new getprogname module) would fail to configure on OpenBSD 5.1. I'll soon push this to gnulib and then update grep's gnulib submodule to latest to pull it in. From d02282b67dcc6d42be8ab89e5ae2122dd01be7b4 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@fb.

Re: [PATCH v2 0/4] New getprogname module

On Wed, Sep 7, 2016 at 11:05 AM, Jim Meyering wrote: > On Wed, Sep 7, 2016 at 10:22 AM, Gisle Vanem wrote: >> Jim Meyering wrote: >> >>> +# elif HAVE_DECL___ARGV >>> + return last_component (__argv); >> >> This should be: >> return last_component (*__argv);

Re: [PATCH v2 0/4] New getprogname module

> if (*__argv == NULL) > return ("?"); > return last_component (__argv); Thanks! I fixed that and the copy/paste error mentioned below with a patch in your name. Will push after you ACK. > And in the test: > > +int > +main (void) > +{ > + char const *p

Re: [PATCH v2 0/4] New getprogname module

+ char const *p = getprogname (); + assert (STREQ (p, "test-getprogname")); + return 0; +} getprogname() would return "test-getprogname.exe" on Windows. Hence a fail. BTW, what is 'base' used for here: # elif HAVE_GETEXECNAME const char *base = getexecname ();

Re: [PATCH v2 0/4] New getprogname module

th MinGW and MSVC have: >> extern char** __argv; >> >> in their . > > Thanks. I will extend getprogname to detect/use that, when possible. I've pushed the attached, which also adds a minimal test case: From 320679aaa13016445f7ba5aba5c7a5a96541d630 Mon Sep 17 00:00

[PATCH] getprogname: port to Solaris 10

* lib/getprogname.c: Include stdlib.h, for getexecname decl. (getprogname) [HAVE_GETEXECNAME]: Use that, for Solaris 10. * m4/getprogname.m4 (gl_FUNC_GETPROGNAME): Check for getexecname. --- ChangeLog | 5 + lib/getprogname.c | 12 ++-- m4/getprogname.m4 | 4 ++-- 3 files

Re: [PATCH v2 0/4] New getprogname module

gram: >> >> checking whether program_invocation_name is declared... no >> checking whether program_invocation_short_name is declared... no > > There are other options; both MinGW and MSVC have: > extern char** __argv; > > in their . Thanks. I will extend getprogname to detect/use that, when possible.

Re: [PATCH v2 0/4] New getprogname module

Jim Meyering wrote: > From the output of that mingw configure run, it appears they are not > declared -- at least not in any header included by this particular > test program: > > checking whether program_invocation_name is declared... no > checking whether program_invocation_short_name is

Re: [PATCH v2 0/4] New getprogname module

On Tue, Sep 6, 2016 at 6:49 AM, Pino Toscano wrote: > Hi Jeremy, > > On Tuesday, 6 September 2016 13:13:52 CEST T J wrote: >> Anyway, it appears that this has not been tested on Windows/MinGW as >> it currently does not work. Everything worked fine with the old >> progname

Re: [PATCH v2 0/4] New getprogname module

PM To: Pino Toscano Cc: bug-gnulib@gnu.org List Subject: Re: [PATCH v2 0/4] New getprogname module On Mon, Sep 5, 2016 at 9:22 AM, Jim Meyering <j...@meyering.net> wrote: > On Mon, Sep 5, 2016 at 7:28 AM, Pino Toscano <ptosc...@redhat.com> wrote: >> On Saturday, 3 September 2016

Re: [PATCH v2 0/4] New getprogname module

Hi Jeremy, On Tuesday, 6 September 2016 13:13:52 CEST T J wrote: > Anyway, it appears that this has not been tested on Windows/MinGW as > it currently does not work. Everything worked fine with the old > progname module. > > A sample build log is here: >

Re: [PATCH v2 0/4] New getprogname module

lib. I needed to check that more in detail, although it's low priority IMHO. > FYI, while adapting grep to use this module, I encountered a single > new error/warning. The attached patch fixes that: Thanks for the fixup. Did you find any other issue there due to the progname -> getprog

Re: [PATCH v2 0/4] New getprogname module

of that should no longer > be done here in gnulib. FYI, while adapting grep to use this module, I encountered a single new error/warning. The attached patch fixes that: From 7a10276e59a05f4176464e0fbadc3f743c8ed244 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@fb.com> Date: Mon,

Re: [PATCH v2 0/4] New getprogname module

On Mon, Sep 5, 2016 at 7:28 AM, Pino Toscano wrote: > On Saturday, 3 September 2016 20:47:15 CEST Jim Meyering wrote: ... > Another thing: should some deprecation warning/note be added regarding > the progname module? I like the idea of adding a deprecation warning. If it

Re: [PATCH v2 0/4] New getprogname module

On Saturday, 3 September 2016 20:47:15 CEST Jim Meyering wrote: > On Thu, Aug 18, 2016 at 6:18 AM, Pino Toscano <ptosc...@redhat.com> wrote: > > as discussed in [1], this series adds a new getprogname module. > > All it does is providing a getprogname function, much like wha

Re: [PATCH v2 0/4] New getprogname module

On Thu, Aug 18, 2016 at 6:18 AM, Pino Toscano <ptosc...@redhat.com> wrote: > as discussed in [1], this series adds a new getprogname module. > All it does is providing a getprogname function, much like what is > found on e.g. *BSD systems, and using it in gnulib instead of progname

Re: [PATCH 0/4] New getprogname module

, 29 March 2016 14:15:18 CEST Pino Toscano wrote: >> >> as discussed in [1], this series adds a new getprogname module. >> >> All it does is providing a getprogname function, much like what is >> >> found on e.g. *BSD systems, and using it in gnulib instead

Re: [PATCH 0/4] New getprogname module

On Wednesday, 17 August 2016 14:14:34 CEST Jim Meyering wrote: > On Wed, Aug 17, 2016 at 6:06 AM, Pino Toscano <ptosc...@redhat.com> wrote: > > Hi, > > > > On Tuesday, 29 March 2016 14:15:18 CEST Pino Toscano wrote: > >> as discussed in [1], this series add

[PATCH v2 0/4] New getprogname module

Hi, as discussed in [1], this series adds a new getprogname module. All it does is providing a getprogname function, much like what is found on e.g. *BSD systems, and using it in gnulib instead of progname. Also, using it explicitly by modules avoids gnulib users the need of either use

[PATCH v2 2/4] Port modules to use getprogname explicitly

... instead of requiring progname to be used (or program_name to be provided). * lib/argmatch.c: Do not include progname.h. [TEST] (program_name): Do not define. [TEST] (main): Call getprogname instead of using program_name. * lib/c-stack.c: Do not include progname.h. (program_name): Do not define

[PATCH v2 1/4] getprogname: new module

This provides a LGPL module for getting the name of the current program, using the same API found on *BSD systems. * lib/getprogname.c, lib/getprogname.h, m4/getprogname.m4: * modules/getprogname: New files. --- ChangeLog | 8 lib/getprogname.c | 45

Re: [PATCH 0/4] New getprogname module

On Wed, Aug 17, 2016 at 6:06 AM, Pino Toscano <ptosc...@redhat.com> wrote: > Hi, > > On Tuesday, 29 March 2016 14:15:18 CEST Pino Toscano wrote: >> as discussed in [1], this series adds a new getprogname module. >> All it does is providing a getprogname function, much l

Re: [PATCH 0/4] New getprogname module

Hi, On Tuesday, 29 March 2016 14:15:18 CEST Pino Toscano wrote: > as discussed in [1], this series adds a new getprogname module. > All it does is providing a getprogname function, much like what is > found on e.g. *BSD systems, and using it in gnulib instead of progname. >

[PATCH 0/4] New getprogname module

Hi, as discussed in [1], this series adds a new getprogname module. All it does is providing a getprogname function, much like what is found on e.g. *BSD systems, and using it in gnulib instead of progname. Also, using it explicitly by modules avoids gnulib users the need of either use

[PATCH 1/4] getprogname: new module

This provides a LGPL module for getting the name of the current program, using the same API found on *BSD systems. * lib/getprogname.c, lib/getprogname.h, m4/getprogname.m4: * modules/getprogname: New files. --- ChangeLog | 8 lib/getprogname.c | 45

[PATCH 2/4] Port modules to use getprogname explicitly

... instead of requiring progname to be used (or program_name to be provided). * lib/argmatch.c: Do not include progname.h. [TEST] (program_name): Do not define. [TEST] (main): Call getprogname instead of using program_name. * lib/c-stack.c: Do not include progname.h. (program_name): Do not define

Re: getprogname

How about this proposal? * Change the progname module to use the BSD getprogname naming convention. No sense reinventing the wheel. That way, programs can simply use the system-defined functions on BSD. * Rewrite the other gnulib code to use the new convention. * Ask gnulib

Re: getprogname

Bruno Haible [EMAIL PROTECTED] writes: It is not so easy. ... d) Don't try to emulate the BSD API at all. Use function names like set_program_name() get_program_name() get_program_base_name() or get_program_short_name(). ... My vote is therefore for d). Me too.

Re: getprogname

* name; if (prog_name) name = prog_name; else { #if defined(HAVE_GETPROGNAME) #include stdlib.h name = getprogname(); #elif defined(HAVE_GETEXECNAME) #include stdlib.h name = getexecname(); #elif defined

Re: getprogname

way around. LibGW32C-0.3 has getexecname (see http://sourceforge.net/project/shownotes.php?release_id=154242), so that function is not unique to Solaris. And LibGW32C-0.4 (see http://gnuwin32.sourceforge.net/packages/libgw32c.htm) has apparently renamed this function to getprogname(). While

Re: getprogname

. Also, http://netbsd.gw.com/cgi-bin/man-cgi?getprogname++NetBSD-current says in NetBSD, calling setprogname() from main() has no effect. Which is also reasonable: you want to allow an application to override system behaviour, not the other way around. Since there's conflicting practice we might

  1   2   >