[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: