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=1.4&content-type=text/x-cvsweb-markup http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/setprogname.c?rev=1.8&content-type=text/x-cvsweb-markup and NetBSD http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/getprogname.c?rev=1.3&content-type=text/x-cvsweb-markup http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/setprogname.c?rev=1.3&content-type=text/x-cvsweb-markup is just the opposite: Whatever may the initial value of __progname be, it is erased when setprogname is called. Which is also reasonable: you want to allow an application to override system behaviour, not the other 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 _not_ providing a setprogname(). > Surely you meant base_name rather than basename? What I presented was only a sketch. Let's discuss details when I show the real code. > How about something like this instead? It's missing the removal of the dirname, of "-" and of "lt-". Also, it lacks a setprogname() function if the system provides getprogname() but not setprogname(). Bruno _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
