Re: Bug#292759: shell script sniplets in /usr/bin?
Santiago Vila wrote:
On Sun, 30 Jan 2005, Matthew Palmer wrote:
"Because I don't wanna play by the rules!" is not a rationale.
You are mistaken. I want to play by the rules, but the rules say
executables should go to /usr/bin, *not* that everything in /usr/bin
should be executable.
It also says that internal binaries not intended to be invoked directly
by users should go in /usr/lib, and that architecture independent stuff
goes in /usr/share.
Actually, it's not even as one way as you think in the definition of
/usr/bin; it says "[/usr/bin] is the primary directory of executable
commands on the system." There's no "and other things that
Santiago/gettext upstream think is appropriate" subclause.
The same could be said for an executable called "ls". Exactly the same.
You do not hardcode /bin/ls in your shell scripts because we already
have the PATH for that. Similarly, there is no reason to hardcode
the location of gettext.sh because we already have the PATH.
Dude, PATH is for programs; gettext.sh is a shell library. It doesn't
really matter that . happens to search PATH for shell libraries --
unless they also happen to be binaries, PATH is just not an appropriate
place for libraries. If you're really bothered by this inconsistency, do
up a patch for bash to get a SOURCEPATH environment variable that can be
set. The whole point of open source software is that we don't have to
live with ridiculous compromises like this -- we can fix the code so
that different things can be separated cleanly and still be properly