Re: /bin/sh (was Re: jessie release goals)
On Tue, May 14, 2013 at 08:59:57AM +0000, Thorsten Glaser wrote:
> Helmut Grohne <helmut <at> subdivi.de> writes:
>
> > What are the benefits of using shells other than dash for /bin/sh? (as
>
> Why does dash get special treatment, anyway? It was ???suddenly??? in
> Debian after having been used in Ubuntu, but??? there never was an
> evaluation of shells.
dash gets special treatment cause it is /bin/sh now. And that happened
because at the time of evaluation it was deemed significantly better
than bash. Which leads us to the real question:
> I still believe the codebase of mksh is better (modulo issues
> introduced due to the active development), but I???m happy with
> freedom to choose one???s own system shell???
Can you quantify those benefits of using mksh? To that end I propose a
few questions, whose answers may help in this discussion.
What issues of dash does mksh solve? How many users are affected?
Is there a benefit in performance? How large is the margin?
> (asides from the two things you mentioned)
>From what you said I count your argument as a "belief" argument, because
it came without data. Sorry.
> ??? or provide an mksh-static binary package. Which could also
> be used in initrd.
Having the same shell for /bin/sh and the initrd actually is something
that can reduce complexity. Did you talk to the initramfs maintainers
about this idea? (Reference?)
Most arguments and weighting of benefits and costs was already done by
Russ Allbery and Steve Langasek, but one thing was not quite right:
Using the diversion mechanism to change /bin/sh is highly risky and was
never supported. Even if Debian only supports running dash (or bash) as
/bin/sh and we ignore problems from broken scripts, there still is the
breakage resulting from the diversion itself. As far as I can tell it
still breaks dash upgrades in all cases. So even the ambitious user
running mksh as /bin/sh and reporting patches for scripts using dashisms
(I never imagined using that word), would be screwed with the next
upgrade.
>From my point of view a change in handling /bin/sh is highly desirable
precisely now, because we all know that the current way is broken and it
was that way for two releases already. Fixing it will cause other
problems (unless all involved parties are geniuses), so fixing it early
in the release cycle is important. As far as I can tell from the huge
bug log partial fixes are already in place and patches are available for
the remainders[1]. IMHO go ahead an break sid now? Waiting longer means
never fixing it or dragging it into the next freeze.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538822#289
Helmut
Reply to: