[Toybox] [PATCH] optional fatter cat(1)

[Roy Tam]

2015-01-05 8:31 GMT+08:00 Rich Felker <dalias at libc.org>:
> 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
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net

 1420418448.0