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 functional.
Cheers, aj