Re: ash vs. bash
This sounds fair enough. I haven't read the source in sufficient
detail, so it may be that there isn't actually a problem, but I'd
really rather someone else checked it out.
> Julian Gilbey <J.D.Gilbey@qmw.ac.uk> wrote:
> > > Proper way to update the link is:
> > >
> > > create new link under some unique name,
> > > rename new link so it occupies the old name.
> > There are two links involved. You have to synchronise them. You have
> > to have proper unwinding. And you have to cope with any potential
> > pre-existing mess. It's non-trivial, but in most cases it seems to
> > work fine. All I was saying was that it would not be wise to trust
> > such software for a system-critical link such as the /bin/sh link.
> > (And I wouldn't use a Perl script for arranging library links either.)
> There's a link from (for example) the /bin/ directory into
> the alternatives directory. If this already exists there's no
> need to change it, if it doesn't exist there's no problem.
> Then there's the link from the alternatives directory back out
> into the /bin/ (again, ferinstance) directory. This is the one
> that gets changed, and this is where care is required.
> Or is there something else that I'm missing?
> [I know that you can have a man page updated in conjunction with the
> executable, but with a little care you can still do this safely:
> create backup of *current* executable link, under a new name,
> if fail, report error and exit
> create new link for executable, under a new name
> if fail, delete backup link, report error and exit
> create a new link for man page, under a new name
> if fail, delete both new executable links, report error and exit
> move the new executable link into place
> if fail, delete all new links, report error and exit
> move the man page link into place
> if fail, rename backup executable link into place,
> then delete new man page link, report error and exit
> delete backup executable link
> Yes, it's possible for the recovery process to mess up, but:
> (a) that's not likely, and
> (b) there's no race condition where the executable is unavailable, and
> (c) even if something really bad happens it's not too hard to clean
> up manually.
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer, see http://www.debian.org/~jdg