2015-01-05 8:31 GMT+08:00 Rich Felker <[email protected]>: > On Sun, Jan 04, 2015 at 06:20:05PM -0600, Rob Landley wrote: >> >> >> On 01/04/2015 01:04 PM, Rich Felker wrote: >> > On Sun, Jan 04, 2015 at 12:39:25PM -0600, Rob Landley wrote: >> >> Coming up with a bash replacement, yay. But dash didn't even bother to >> >> implement "source" as an alias for ".", or implement the "function" >> >> keyword (it's basically a comment). Those were trivial bash flavoring >> >> things that would be like 5 minutes coding, and they explicitly chose >> >> _not_ to do that because they did not _want_ compatibility. >> > >> > I see those things as roughly equivalent to <sys/poll.h> and >> > <sys/fcntl.h> in musl -- or maybe even <sys/cdefs.h> which musl >> > doesn't have. >> >> http://landley.net/hg/aboriginal/rev/540 >> >> I want stuff to _work_. Throw warnings sure, but if something is >> actually _using_ it... >> >> > These are not useful features but coddling of spelling >> > mistakes made in non-portable code. And it's a matter of opinion, >> > where both sides have valid points, whether it's better to pressure >> > people to fix those spelling mistakes or simply work around them. >> >> Indeed. I come down on the side of having a dos box you can confine old >> code to so it still works, and have -Wall to let you fix new stuff. >> >> You've seen the lengths I went to in aboriginal to do host/path and >> more/record-commands.sh and forensically determine exactly what was >> going _on_ in the builds and the specific requirements down to the bare >> metal. Heck, I worked out the minimal kernel .config that had the system >> calls I needed. >> >> But then what I _ship_ includes linux from scratch chroot tarballs >> because other people reproducing my minimal environment is science, but >> other people starting with a lfs tarball is engineering. >> >> >> (Stuff like >> >> implementing path/to/{one,two,three} curly bracket support would be more >> >> like a weekend of coding, but still: that not being there broke stuff.) >> > >> > Additional features like that also cause incorrect behavior in >> > non-bash scripts unless they're off-by-default. >> >> Except that on Linux, "non-bash scripts" were almost nonexistent before >> 2006 (ported from other OSes and you know where to find ksh or zsh if it >> says #!/bin/zsh), and even since then it's still a minority and not very >> _interesting_. > > Every single practical configure script (autoconf generated or written > by hand) is a non-bash script. That's quite a huge portion of shell > scripts. And they've been around since the beginning on Linux. > >> I view posix sh -> bash much the way I System V -> Linux. (System V >> didn't have procfs. I'm writing stuff that uses procfs. There are >> compatability modes that implement that in BSD, and limiting yourself >> to /etc/mtab not being a symlink to /proc/mounts means you're not >> dealing with reality on modern system. You _can't_ get that right >> entirely in userspace these days.) > > These are all implementation details that matter only to a few > boot-time utilities and such. They're all irrelevant to applications. > It's stupid and inappropriate for applications to assume procfs or > mtab or even the concept of mounts, which won't exist on future > systems when Linux is considered a dinosaur... This is why the > standards omit them. Standards are about what an application can > expect to see, not how it gets done under the hood. They're about > moving us forward into compatibility and interoperability, not > backwards into lock-in to outdated implementation details. > >> >> I repeat: ubuntu made a bad technical decision, gratuitously breaking >> >> compatibility for its existing userbase for a stated reason that was >> >> inadequate to justify the fallout, one which could easily have been >> >> accomplished a different way without end user impact, and fairly quickly >> >> _was_ because it didn't accomplish its stated goal but the change was >> >> retained anyway. >> > >> > I think the security and runtime-cost benefits were more than >> > sufficient to justify the "fallout". >> >> I see no benefits. > > 2x VSZRW, 5x actual ram usage (dirty pages), per instance. > > And anecdotally (I don't have figures) performance is considerably > better. > > And of course, most importantly, complete lack of function exports and > other dangerous code paths processing potentially untrusted data that > should never have existed in the first place. > >> > The broken scripts are easily >> > remedied just by fixing the #! line, or they can be made portable if >> > that was the intent to begin with. >> >> Every script I know changed the #! line, but that was a bug workaround >> for ubuntu breaking the /bin/sh symlink. > > Every script you know? No, some small set of bash scripts that were > wrongly labeled as sh scripts. The vast majority of the scripts you > know are configure scripts and most of them even run on ancient > pre-POSIX shells. >
IIRC busybox sh even has some bash extensions. But form my point of view, using mksh(Android default shell since ICS) seems to be better since Thorsten Glaser keeps fixing bugs. > Rich > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
