Re: shell script sniplets in /usr/bin?
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.