Hi Pádraig,
> I noticed a discrepancy in the program name output by error(),
> which looks to be due to whether the gnulib or glibc version is used.
> If we use gnulib's error() it uses getprogname()
> which defaults to program_invocation_short_name.
> The glibc error() instead uses program_invocation_name.
>
> I don't know why gnulib differs in that regard
Here's the explanation:
- We want error() to be usable in library code or, at least, in code
that does not impose requirements on the main() function.
This was done on 2016-08-08 by Pino Toscano.
- The function that this uses, getprogname(), returns the base name,
because we like to have the same behaviour across platforms, and on
most platforms the full program name is not available. (Look at the
amount of hacks needed to get only the base name!)
The comments in progname.c indicate the intention to keep glibc's
variables in sync with what the caller is passing to set_program_name().
> I've not looked into why coreutils is using the gnulib error()
> given that REPLACE_ERROR=0 and HAVE_ERROR=1
It's because of
m4_ifdef([gl_HAVE_MODULE_VERROR],
[COMPILE_ERROR_C=1],
...
in m4/error_h.m4. coreutils apparently uses the module 'verror'.
> but in any case program_invocation_name and program_invocation_short_name
> should be consistent with each other.
I agree.
> This is not the case because set_program_name()
> only sets program_invocation_name normally.
Can you describe the circumstances where you observed the discrepancy?
> The attached patch also sets program_invocation_short_name
> and results in coreutils' tests passing in all cases.
The patch would look cleaner, I think, if the fix would be placed
around line 92, not around line 71. Also there's an indentation problem.
Bruno
