Re: /etc/init.d scripts WAS: Re: start-stop-daemon on Debian (fwd)
On 19-Apr-99, 02:26 (CDT), Brock Rozen <brozen@torah.org> wrote:
> Yes, it does require a lot of people to make modifications to a lot of
> scripts -- but it certainly doesn't require modifications again if the
> root path ever changes. Why? Because these script are appending what THEY
> need, even if it's already in the root path. That doesn't hurt the path,
> ensures that the user set root path is used first and that the script will
> run fine, even if that user set root path changes to something
> unreasonable.
Sorry, I confused the issue by using the phrase "root's path" as
short-hand for "the sane root path which contains the standard binary
directories". My point is that if for some reason a bunch of the
standard programs move to some other directory, then that new directory
will need to be added to all the scripts. The scripts don't *know* what
paths they need, except by convention. Is that convention likely to
change? Probably not, but it *has* happened in the past (/etc -> /sbin
and /usr/sbin), and ignoring the possibility that it will happen again
is shortsighted.
> Right. And how does APPENDING a path statement store copies of it in each
> place? I understand the concept, and am not asking each script to store
> the main root path, but to append what IT needs, and only what it needs to
> run. But since we're appending, we're not overwriting and we're
> incorporating it by environment variable and not hard-coding what the
> parent path is but refering to it by it's environment name.
If you put "PATH=$PATH:/bin:/usr/bin:/sbin:/usr/sbin" then you've
hardcoded a good chunk of the *standard* root path in each script. If
that changes, then you've got to go back and fix each script.
And appending doesn't really help. If you assume that you can't trust
root's path, then you have to override it, or else you just trade one
set of problems ("can't find route") for another ("oops, just found
a executable called 'route' in /root/bin, which does something else
entirely").
I think we'll probably be stuck going back and forth on this, because I
disagree with the fundamental philosophy (as I outlined in my previous
message, and upon which you chose not to comment). Short version: the
sysadmin has a responsibility to maintain a sane envirorment for the
root account. Providing facilities that encourage weakening of that
responsibility is not good training for budding sysadmins.
Steve
Reply to: