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

[Rob Landley]

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