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

[Rich Felker]

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.

Rich