Bill Allombert <[EMAIL PROTECTED]> writes:
> Hard-coding path is frowned upon theses days and there is no standard
> way to disable a shell built-in, so in practice we are actively
> prevented from using coreutils test and thus coreutils test features. So
> the question is not merely what should be the default.
Who is arguing that you can't use /usr/bin/test when you explicitly need a
feature of coreutils test? The relevant Policy section says:
Programs called from maintainer scripts should not normally have a
path prepended to them. Before installation is started, the package
management system checks to see if the programs ldconfig,
start-stop-daemon, install-info, and update-rc.d can be found via the
PATH environment variable. Those programs, and any other program that
one would expect to be on the PATH, should thus be invoked without an
absolute pathname. Maintainer scripts should also not reset the PATH,
though they might choose to modify it by prepending or appending
package-specific directories. These considerations really apply to all
shell scripts.
That's a "should normally," not a must, and this sort of situation is
seems to me to be exactly why it says "should normally" instead of "must."
The reason for not prepending a path is that it's pointless and may create
problems later if the binary moves. The first is not true in this case,
and I don't think the second is strong enough by itself.
In fact, if you squint the right way, that paragraph gives a sort of
blessing to using an absolute path in this situation, since coreutils test
is not quite "any other program that one would expect to be on the PATH"
simply because in this case the shell isn't going to *look* at the PATH.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
