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 warning

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 getp

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 cur

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

On 2021-09-22 3:49 p.m., Bruno Haible wrote: > Hi John Dave, > > According to > https://en.wikipedia.org/wiki/HP-UX#Version_history > versions < 11.31 of HP-UX are already past end-of-support for more than > 5 years. The only possibly relevant HP-UX version nowadays is 11.31. > > Therefore I would

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

Hi John Dave, According to https://en.wikipedia.org/wiki/HP-UX#Version_history versions < 11.31 of HP-UX are already past end-of-support for more than 5 years. The only possibly relevant HP-UX version nowadays is 11.31. Therefore I would not want to spend time on the earlier versions. We have al

Re: getprogname and libtool

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

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. Bruno: > Fully agree on thi

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 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/t

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 > > set_program_name() function shou

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

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 us

Re: getprogname and libtool

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

Re: getprogname and libtool

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

Re: getprogname: comments and test failure on Cygwin

On Tue, Oct 18, 2016 at 6:07 AM, Daiki Ueno wrote: > Hello, > > Jim Meyering writes: > >> On Sun, Oct 16, 2016 at 5:15 AM, Pádraig Brady 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 "tes

Re: getprogname and libtool

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,

Re: getprogname: comments and test failure on Cygwin

Hello, Jim Meyering writes: > On Sun, Oct 16, 2016 at 5:15 AM, Pádraig Brady 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-getprogname.exe". (On mingw, on the >>

Re: getprogname: comments and test failure on Cygwin

On Sun, Oct 16, 2016 at 5:15 AM, Pádraig Brady 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-getprogname.exe". (On mingw, on the >> other hand, it really is "test-getpro

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".) > > Also, while at it, I'd like to add comments

Re: getprogname() for IBM z/OS

On Thu, Oct 13, 2016 at 1:10 PM, Jim Meyering wrote: > 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

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, I see, the program nam

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

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 ifs are redundant. Revised patch is tested and attache

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 (&buf, 0, sizeof(buf)); > + buf

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

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

Re: getprogname

Bruno Haible <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> This isn't as compatible as possible with BSD, as BSD setprogname >> ignores its argument when the true program name is available from >> the operating system. > > Huh? My reading of the sources of FreeBSD and NetBSD is just the > op

Re: getprogname

Paul Eggert wrote: > This isn't as compatible as possible with BSD, as BSD setprogname > ignores its argument when the true program name is available from > the operating system. Huh? My reading of the sources of FreeBSD http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/getprogname.c?rev=

Re: getprogname

Bruno Haible <[EMAIL PROTECTED]> writes: > Well, my intention is basically this: A few comments. This isn't as compatible as possible with BSD, as BSD setprogname ignores its argument when the true program name is available from the operating system. LibGW32C-0.3 has getexecname (see

Re: getprogname

Peter O'Gorman wrote: > Solaris seems to have a getexecname Interesting. So this provides a fallback, like on glibc systems, for the case when setprogname(argv[0]) has not been called. > I'd suggest the following instead of Paul's proposal, as it allows > the programmer to override the program na