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

[Rich Felker]

On Sun, Jan 04, 2015 at 12:39:25PM -0600, Rob Landley wrote:
> >>>> (Redirecting /bin/sh to point to dash instead of bash was still a dumber
> >>>> move, though.)
> >>>
> >>> I fail to see how this was dumb. It made shellshock a non-issue
> >>
> >> When they switched to dash I _segfaulted_ the thing multiple times. It
> >> was a buggy pile of crap for _years_.
> >>
> >> It's interesting you think shellshock was a non-issue, presumably that's
> >> why it didn't make the news or anything? (I'm consistently amused that
> > 
> > I don't think shellshock was a non-issue. I just think it was mostly a
> > non-issue for systems that don't use bash as /bin/sh or their login
> > shell for restricted accounts (forced command in authorized_keys
> > file), and this is one reason I think it was a good move not to make
> > /bin/sh be a link to bash.
> > 
> > Yes some people write crappy scripts that depend on bash but don't use
> > #!/bin/bash. I don't and I don't like paying the penalty for people
> > who do this. They should fix their broken scripts, and preferably they
> > should write portable shell script instead of bash. I suspect you'll
> > be more agreeable to this position once more bash-specific scripts
> > start depending on post-GPLv3 versions of bash... :-)
> 
> No, I'm implementing the non-crazy bash extensions people actually use
> in toysh. (Toybox should eventually be able to build itself including
> its own "sed" invocations and its own shell to run scripts/*.sh.) This
> is why I went to the "advanced bash scripting" talk at Texas LinuxFest,
> to see what tricks that speaker felt were worth knowing/using (and thus
> implementing).

Nothing wrong with that; if it helps eliminate bash from more systems
I'm quite happy to see it happen. But...

> 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. 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.

> (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.

> 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". 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.

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.

Rich