Santiago Vila wrote:
On Sun, 30 Jan 2005, Jochen Voss wrote: I suggest that you read the reply by the author. For the benefit of those who don't have web browsers, I'll quote it here: gettext.sh is meant to be sourced from shell scripts, using the "." command. This command looks in $PATH, but none of the subdirectories of /usr/share/gettext is present in $PATH.
Which is nice, but since gettext.sh can't go in PATH because it's not an executable, that feature of /bin/sh isn't useful. Instead, you need to include the full path to gettext.sh when sourcing it.
So, the common sense says /usr/bin is ok for gettext.sh, not the opposite.
Features of random programs, even /bin/sh don't indicate where you should put things on the filesystem; anymore than a program that has its config files hardcoded to be in /root/foobar.conf means it's okay for the Debian package of that program to put them there. We demand the right to change programs precisely so that we can make their behaviour conform to our expectations; instead of having to have to engage in doublespeak to make it seem like things aren't /really/ at odds with how the rest of the system operates.
If you want to make policy that /usr/bin should only contain executables, go ahead, make a policy proposal,
There is no policy issue here -- the FHS is already entirely clear on this; /usr/bin is for executables, which gettext.sh is not.
but none of you have answered to the question made by Frank Küster: Do you think we should simply not make any use of the POSIX feature that . $name will look for $name in the $PATH? Or do you think we should add a directory to PATH that is then dedicated to such shell snippets?
Neither. Shell snippets should not go in PATH unless they also happen to be programs. That's not the empty set, though it's probably close. Meanwhile it's completely reasonable to make . look in directories other than $PATH for shell snippets if such a feature is needed.
Cheers, aj