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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130515065550.ga12...@alf.mars