On Fri, Apr 15, 2016 at 12:40 PM, Andy Chu <[email protected]> wrote: > On Fri, Apr 15, 2016 at 10:16 AM, enh <[email protected]> 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
