A few dependency conditions can be improved a little bit:
2024-09-02 Bruno Haible
error, getprogname: Stricter dependency conditions.
* modules/error (Depends-on): Add dependency condition.
* modules/getprogname (Depends-on): Make dependency condition stricter
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
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
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
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
you sure the offsets 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
status64 + 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
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
se
Thanks, I installed that in your name.
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 02:27:02.835632
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
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
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
+#if
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 i
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.
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 mo
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 JI
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&
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.
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 libffca
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.
>
>
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
module
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 Ha
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.
Thank
>= 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 (bu
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
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 pro
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
> __SCO_VERSION_
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 some
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 fou
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&mansection=&lang=en
> Is where the predefined constants for the
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? (SCO'
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 y
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 th
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 __sysv5__
+# include
Now that 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)
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__
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 "="
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 "
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 t
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
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
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
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
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
rors detected in the compilation of "../../lib/getprogname.c".
This patch fixes it.
2017-11-11 Bruno Haible
getprogname: Fix compilation error on IRIX.
* lib/getprogname.c (getprogname) [__sgi]: Fix type of local variable
'namesize'.
diff --git a/li
* 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/Chan
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
>>
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
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
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 Ji
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_na
Padraig Brady and Jim Meyering wrote:
> > All improvements look good to me.
>
> Likewise.
OK, I pushed it.
t; 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 out
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 fr
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 possib
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&
nstall",
> * 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 lea
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
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
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&q
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-getprogn
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. Th
hed.
>>
>> 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 Mon Sep 17 00:00:00 2001
From: Jim Meyering
D
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
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
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
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
Please double-check the use of strdup(), to avoid memory leakage.
2016-10-12 Daniel Richard G.
getprogname: port to IBM z/OS
* lib/getprogname.c (getprogname) [__MVS__]: Use getpid,
w_getpsent and strdup to obtain the program name string.
--Daniel
--
Daniel
On Wed, Sep 28, 2016 at 11:28 AM, Jim Meyering 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 tested on Fedora
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
Dat
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);
>>
>> Or with a bit more care:
>>
ULL)
> 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 = getprogname ();
> + asse
+ 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 = getexec
this particular
>>> test program:
>>>
>>> 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 c
In data martedì 6 settembre 2016 23:57:05 CEST, Paul Eggert ha scritto:
> * 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.
> ---
Thanks f
* 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
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.
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 de
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 module.
>>
>> A sample b
] New getprogname module
On Mon, Sep 5, 2016 at 9:22 AM, Jim Meyering wrote:
> 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
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:
> https://ci.appveyor.com/project/fontforge
e 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 -> getprogname switch?
Thanks,
--
> 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
Date: Mon, 5 Sep 2016 21:40:57 -0700
Subject: [PATCH]
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 could be completely repl
On Saturday, 3 September 2016 20:47:15 CEST Jim Meyering wrote:
> On Thu, Aug 18, 2016 at 6:18 AM, 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
On Thu, Aug 18, 2016 at 6:18 AM, 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.
> Also, using it e
; >> 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 mo
On Wednesday, 17 August 2016 14:14:34 CEST Jim Meyering wrote:
> On Wed, Aug 17, 2016 at 6:06 AM, Pino Toscano 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.
&
... 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
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 the
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
On Wed, Aug 17, 2016 at 6:06 AM, Pino Toscano 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 like what is
>> foun
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.
> Al
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 the
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
... 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
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
> > 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 o
was assuming NetBSD, since it introduced the feature. 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
> syst
1 - 100 of 103 matches
Mail list logo
