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

[Andy Chu]

On Fri, Apr 15, 2016 at 1:51 PM, enh <enh at google.com> wrote:
> On Fri, Apr 15, 2016 at 12:40 PM, Andy Chu <andychup at gmail.com> wrote:
>> On Fri, Apr 15, 2016 at 10:16 AM, enh <enh at google.com> wrote:
>>> things to avoid/reasons why i'd happily get rid of mksh in Android:
>>
>> OK interesting -- can you say more about the use cases of shell and
>> toybox in Android?
>>
>> For example, why does Android need toybox expr?  Does some shell
>> script use it?  I only know a little about Android (from building AOSP
>> 18 months ago), but my impression was that the use of shell scripts
>> was limited, and they were all "in-tree" so you can patch them.
>
> Google isn't the only one shipping Android devices :-)

OK I see... so if Samsung or whoever wants to put a new daemon on
Android, then it might use expr in its init script.  And obviously
they have their own private forks which we can't see.

I know that builds and autoconf in particular make a lot of usage of
shell and expr, as Rob shows.  But  it seems to me that compiling
software on Android devices isn't currently a particularly big use
case (not to say that it shouldn't be).

> there are things that are worth fixing even if the world has to
> change. but this isn't one of them. there's almost no cost to
> including expr, POSIX says it should be there, and there's no obvious
> advantage to us in not shipping it.

OK but I was wondering why you pulled expr out of pending, rather than
using the defconfig build.  expr was WILDLY broken -- it gave the
wrong answers to MATH, and it segfaulted on trivial inputs like
matching a number-like string with a regex.

I was worried that somebody would rely on the current broken expr
behavior, but as I understand it, every Android release is basically a
clean slate...  if a current expr user relied on broken behavior in
Android M, then with Android N or whatever it would be up to them to
fix their shell script.  Is that correct?  It would likely be a shell
script in their private tree so that would have to be the case I
think.

Likewise, if you decided to change the shell, you wouldn't worry about
minor breakages?  I think the shell has already changed once, right?
And it was probably mostly a superset but not strictly a superset.


> so far i've only really worried about platform developers, yes. longer
> term i plan on having a static toybox binary in the NDK too: for
> non-platform developers, the version in your NDK will always be at
> least as recent as the one on the device. so why suffer old bugs when
> you can just push a known-good copy?
>
> (see how many times "sed is broken on Android M" gets reported, for example.)

Can you explain this a little more?  I would imagine that people use
sed on the host with the NDK, to build shared objects and so forth,
which they will then transfer over to the device with their app to
test.  But is sed used at runtime on the Android device if you're
writing code with the NDK?

Or is it for having parity between a simulator on the host and the device?


> but, yeah, the shell is probably less interesting to app developers.
> they're likely to be running "adb shell ..." from their desktop's
> shell rather than using a shell on the device. (not least because "adb
> shell" was basically unusable on Windows until recently.)

OK, understood.  Thanks for the explanation.

Andy