> > 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 users to switch to the new convention.
>
> Yes, that's the most sensible thing to do.
It is not so easy.
There are two problems:
1) BSD error handling routines use getprogname()
= essentially base_name(argv[0]).
GNU error handling routines use
program_name = essentially argv[0]
likewise on glibc: program_invocation_name, not
program_invocation_short_name
You can see the visible difference in behaviour on a MacOS X machine
which has a BSD 'mv' in /bin/mv and a GNU 'mv' too:
$ /bin/mv junk /etc/
mv: rename junk to /etc/junk: Permission denied
$ /gnu/bin/mv junk /etc/
/gnu/bin/mv: Verschieben von „junk“ nach „/etc/junk“ nicht möglich:
Permission denied
I find the GNU behaviour better designed, because when a program is
called with a full or relative pathname, it's usually because it's
not in PATH or not the first one in PATH, and the GNU error handling
gives more information as of which 'mv' program gave the error message.
Whereas BSD's error handling behaviour makes the user think that the
error message came from "the" 'mv' program - although "the" 'mv' in
my PATH is actually /gnu/bin/mv.
2) getprogname() returns something different than the argument of
setprogname(). Would be acceptable if the difference was small, but
as 1) shows, it does matter.
We have 4 options:
a) Change the behaviour of error() to be like on BSD, using
the equivalent of program_invocation_short_name instead of
the equivalent of program_invocation_name.
b) Add an accessor function getprogpath() or similar, that is
then used by error.c.
c) Add an accessor function getprogbasename() or similar, that
corresponds to what BSD getprogname() does, and change getprogname()
to be like program_invocation_name.
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().
The drawback of a) is less transparency for the end user, and a different
behaviour than glibc.
The drawback of b) is that it's confusing for the developer:
getprogpath() returns the value set with setprogname(), and getprogname()
returns something different.
The drawback of c) is that our functions have the same names as the BSD
ones but do something different.
My vote is therefore for d).
Bruno
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
