Re: Recovery tool placement
Stephen Harris writes:
> Matthew writes:
> > If we think we need tar/cpio in /bin for restoration purposes
> > OK, but do programs really call tar with an absolute pathname?
> >
> > I mean they shouldn't; they should just use a standard PATH
> > and assume tar is available in that standard PATH.
>
> They "shouldn't" is a wonderful theory, but in practice programmers DO work
> this way. How about C programs that use external programs. Kermit calls
> "/bin/ls" or "/usr/bin/ls" depending on how it is compiled.
> Some Configure scripts use #!/bin/echo to determine if #! works on your system.
>
> It is quite within the realms of reasonableness that programs will try and
> call /usr/bin/tar or /usr/bin/cpio.
I raised this point before, but almost all problems of this nature can
be fixed in the following manner:
1. Move all the programs that need to be in /bin to /sbin
2. Link those programs to /usr/bin.
3. Link /bin to /usr/bin.
This is compliant with the FSSTND, and from then on one does not have
to worry about whether csh is in /bin or /usr/bin. The users' path
variable is also shorter, since it need only contain /usr/bin or /bin,
but not both. The only place where caution is needed is in the
various scripts run at boot time, but they are only a few in number
and this should be a managable task.
I did propose this a while ago, but there was not much enthusiasm for
this. The main objection raised was that `it needs too many
symlinks', or that it was simply `inelegant'. But I can see that the
draft is already moving in that direction by requiring things like
`/bin/csh -> /usr/bin/csh'. Why not go all the way then, and put this
issue at rest forever?
--
Sunando Sen
Dept. of Economics Email: sens@acf2.nyu.edu
New York University
Reply to: