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

[enh]

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 :-)

> So if you had some upstream packages that used shell for an init
> script or something, you could patch it to use $(()) in mksh instead
> of expr, and avoid expr.  Or maybe it's just not worth the effort to
> do that, and it's easier to have expr on there.  (I thought I was the
> only one who used expr :) )

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.

> Who uses the shell?  I would have guessed it's for the boot process
> mainly?  I don't think people are installing compilers on Android
> phones and building GNU packages, but I could be mistaken.  And I
> would think the main use cases right now for toybox are on the device,
> not for platform and NDK builds, no?  But maybe it is useful for build
> with toybox to make the build hermetic.  I know all the compilers are
> vendored in.

no, we don't use toybox for the host. its awkward configuration
process makes that pretty unlikely too. if/when toybox gets
gen*fs/mk*fs toys, it'll be worth looking into. but right now there's
no point.

> I imagine the big users now are not end users or app developers, but
> platform developers (e.g. Samsung engineers) who need to tweak things
> when bringing up the OS on new hardware.  I'm able to run toybox on my
> Nexus 5x via ConnectBot, though honestly I'm not sure what to do with
> it since it's limited to an individual app UID  :)

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

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

> I think it would be cool to have my shell on Android, and it's written
> in Google-style C++ like Ninja like I said, with unit tests, no
> globals and (tasteful) dependency injection and everything.  It's only
> 2 weeks of work and 2800 lines of code now, so that's a long ways off
> :)
>
> But I'm curious about the use cases.  I think I can probably get some
> other shell users at Google to contribute, because I've done a lot of
> the hard parts in a clean way.  Lexing and parsing shell are
> particularly hard IMO; compare with mksh's yylex() and associated
> macros in lex.c, which is about 1000 lines in a single function, and
> it only does part of the job my lexer does.
>
> thanks,
> Andy



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