On Sun, Jan 30, 2005 at 02:28:01PM +0100, Santiago Vila wrote:
> So, the common sense says /usr/bin is ok for gettext.sh, not the opposite.
s,common sense,convenience for the author/maintainer,
> If you want to make policy that /usr/bin should only contain executables,
> go ahead, make a policy proposal, but none of you have answered to the
think about the purpose path is supposed to serve. the bash man page
says PATH is "The search path for commands". it mentions nothing of
shell scripts to be included/sourced. i don't think a policy proposal
is necessary, i think all that is necessary is that you take a step
back from your situation and seriously reflect this.
> 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?
i already provided a two methods which still allow for th is
functionality while not requiring you to drop gettext.sh in /usr/bin.
1)
(inside a gettext.sh using script)
#!/bin/sh
PATH=${PATH}:/usr/share/gettext/scripts
. gettext.sh
2)
#!/bin/sh
if [ "$GETTEXT_PATH" ]; then
GETTEXT="$GETTEXT_PATH"
else
GETTEXT="/usr/share/gettext/scripts/gettext.sh"
fi
. $GETTEXT
note that i'm not advocating you immediately change this, as someone
else pointed out this would break a lot of stuff. i am however
saying that your "that which is not explicitly denied must be allowed"
reasoning is flawed and is formed from your own bias to not have to
inconvenience yourself.
sean
--
Attachment:
signature.asc
Description: Digital signature