Re: Bugs in bash (was: Release-critical Bugreport)
Hi,
On Tue, 1 Jun 1999, Steve Greenland wrote:
> Oh yeah, but you might hear a bunch of griping from your users while
> you were educating them. I certainly don't have any objection to
> "supporting" alternative /bin/sh, and for that matter, wouldn't mind
> changing the default: there seem to be some good reasons to do so.
> But if we do something like this, we need to be ready for a lot of
> complaints/objections/whining.
I agree with your observations and I must say: you have my sympathy ;->
But seriously, I agree that, given the circumstances, it should not
be forced upon users and sysadmins alike that /bin/sh suddenly behaves
like a proper Bourne shell and no more than that. But Debian can
perfectly well handle a change that is not forceful and irreversible,
via the alternatives mechanism and smart postinst scripts.
On existing systems, /bin/sh can be changed to use the alternatives
mechanism, setting the current choice for /bin/sh as the manually set
preference. On new systems, it can be setup in "auto" mode, pointing
to whatever shall be decided will be Debian's default /bin/sh. IMHO that
should be something small and lightweight like ash.
Making the change in this way guarantees that existing setups won't break
suddenly and without warning, while allowing the administrator to tweak
to his particular preferences. New systems OTOH can be setup using "a
better standard" without risking breaking some user's setup, because new
systems generally don't have any users yet. And remember that copying
your #!/bin/sh scripts that work just fine on Debian will also break
when transferred to any other *nix that implements a proper Bourne shell.
On Wed, 2 Jun 1999, Remco Blaakmeer wrote:
> If the /bin/sh link will be maintained through the alternatives system,
> bash should still have the highest priority, IMO. That way, there is no
> problem for people that don't want to change the link.
I agree with that regarding existing systems. New systems should have it
"The Right Way(tm)", whatever that may be decided to be.
> I think there should be a proper sh(1) man page in this case, which is NOT
> linked to the bash(1) man page. It should list all features /bin/sh can be
> expected to have, and nothing more.
That would be kind of hard to implement in the current situation.
What package should provide that sh(1) manpage? People will complain
that their sh(1) doesn't document /bin/sh's actual behaviour if it so
happens to be that their sh is bash. The manpage should also document
the way Debian handles sh.
Maybe the best solution is to have a package shells-common providing
a generic sh(1) manpage. That package could then also be the owner of
/etc/shells, maybe provide an interface to add and remove shells from
that file dynamically. Other examples of configfiles that could be
managed by this proposed package are /etc/profile and /etc/environment.
Cheers,
Joost
Reply to: