This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] sln: Install as a hard link to ldconfig
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 2 Aug 2016 15:49:47 +0000
- Subject: Re: [PATCH] sln: Install as a hard link to ldconfig
- Authentication-results: sourceware.org; auth=none
- References: <20160713121747.6F56A401AE80B@oldenburg.str.redhat.com> <20160721062237.GG6702@vapier.lan> <c9e687d8-6ee3-96f6-c0ff-c9d98e6f28ce@redhat.com>
On Tue, 2 Aug 2016, Florian Weimer wrote:
> Can you provide an exact quote? I don't see it. coreutils supports this, and
> bash pretty much requires looking at argv[0].
There are at least two relevant quotes in standards.texi:
@node User Interfaces
@section Standards for Interfaces Generally
@cindex program name and its behavior
@cindex behavior, dependent on program's name
Please don't make the behavior of a utility depend on the name used
to invoke it. It is useful sometimes to make a link to a utility
with a different name, and that should not change what it does.
Instead, use a run time option or a compilation switch or both to
select among the alternate behaviors. You can also build two versions
of the program, with different names and different default behaviors.
and, for --version:
The program's name should be a constant string; @emph{don't} compute it
from @code{argv[0]}. The idea is to state the standard or canonical
name for the program, not its file name. There are other ways to find
out the precise file name where a command is found in @code{PATH}.
--
Joseph S. Myers
joseph@codesourcery.com