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_. 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.) >> 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. > 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. > If there were cases where dash really was technically worse than bash > (like crashing, memleaks, etc.) then that's another matter, but I > think they just indicate that the switch was made prematurely rather > than that it was wrong in concept. This was not an either/or situation, it was both. > Rich Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
