Re: shell script sniplets in /usr/bin?
sean finney <seanius@debian.org> writes:
> 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
Reverse that, put gettext scripts first so they do source the right
files.
> 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
MfG
Goswin
Reply to: