Re: ash vs. bash

[Raul Miller <moth@magenta.com>]

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.)

Huh?

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.

-- 
Raul