[Toybox] [PATCH] Implement mv -n / cp -n (no clobber).

[Rob Landley]

On 03/27/2016 01:46 PM, Andy Chu wrote:
>> 3) Security features for distributed systems ... sh is obviously not
>> designed for untrusted input (including what's on the file system).
> 
> 4) ... along these same lines, a lot of other people are annoyed by
> the gratuitous and crippled shell in make:
> 
> https://github.com/apenwarr/redo -- implementation of a DJB design,
> each rule is a shell file, so you automatically get the property that
> changing the command line/rule invalidates the output, which Make
> doesn't have)
> 
> https://github.com/danfuzz/blur -- from the author of the Android.mk
> system (which slurps a big tree Make fragments into a single
> namespaced Makefile).  I guess he got sick of Makefiles after that ...
> 
> Both of these have issues but are interesting... I think it wouldn't
> be too hard to make a shell in which you could IMPLEMENT make.  It
> seems like you've gone a little in that direction with your "isnewer"
> checks in scripts/make.sh!

Writing a new _make_ is very interesting to me. That desperately needs
to be replaced, as I explained in the "make rant" URLs I linked to last
message:


http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000859.html


http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html

However, Elliott told me Android is in the process of doing that:

  https://twitter.com/landley/status/691668319481364480

I really need to look into that build system. It's on the todo list. :)

(But that won't get me out of implementing a make that can build Linux
>From Scratch and Buildroot and so on. If that has gnu extensions, then
it has gnu extensions. If it needs a built-in shell, it can use toysh.)

> The problem is that all this stuff is at the foundational layer, and
> being backward compatible with both shell AND make is a very tall
> order (although I guess that's where my interests overlap with toybox)

I make it compatible with real world test data. You just have to collect
a large enough corpus of real world test data, plus whatever "standards"
you feel are worth looking at (general posix and man pages), and then
have at and do a lot of debugging as people use it and it breaks for them.

At a certain point using your users as guinea pigs is unavoidable. The
goal is to minimize it so you're not being _impolite_ to them by having
them find problems you could have found yourself.

> Andy

Rob

 1459148016.0