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

[enh]

On Fri, Apr 15, 2016 at 3:48 PM, Andy Chu <andychup at gmail.com> wrote:
> 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 certainly people who sit not too far from me who think
that's fun, but, no, that's not really what i'm aiming at.

as my "Future command-line work" slide at the last couple of Android
partner bootcamps has said:

* No one misses busybox/coreutils --- our command-line tools “just work”.

* All the useful developer commands, with all the useful options.

i love replying to "how do i do <shell one-liner> on the device?"
questions with "<same shell one-liner>" :-)

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

iirc, "because it's POSIX, and we hadn't had _any_ expr before, and
something is better than nothing, and you don't get bug reports if you
don't ship".

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

relying on bugs is [mostly] not supported. sometimes a bug is relied
upon by everyone, in which case it's no longer really a bug. but
usually we consider ourselves to be at liberty to fix any bug.

(and although most devices aren't built directly from our tree, the
only devices i'm required to keep building are the ones in our tree,
and -- as you said earlier -- if it comes to it i can fix them all
myself.)

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

the previous shell was so bad everyone cheered when it went away. the
same was true for some of the old toolbox stuff. but some of the
toolbox -> toybox transition was tricker. it's still not complete! the
main reason i haven't switched ps and top is that they don't support
threads, but most of the minor issues we've had to work through have
involved output formats. ls wasn't in M (but is in N) because i had to
fix a *lot* of code that was parsing the old (non-POSIX) output. in
other cases we've had to change toybox to have traditional Android
defaults when running on Android.

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

i've no idea what folks are using it for. maybe just shell one-liners,
maybe they have weird scripts. _someone_ probably is building python
on the device rather than cross-compiling it.

> 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



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.