[Toybox] runcon requires CONFIG_TOYBOX_NORECURSE=y

[Rob Landley]

On 01/20/2016 11:21 PM, enh wrote:
>> Over in my Aboriginal Linux project I've had my nose recently rubbed in
>> the need to start work on toysh (hush is crap, ash doesn't support
>> nommu, and bash 2.05b from the dawn of time is coming to the end of its
>> usefulness), and one of the things the recent utf8 fontmetrics stuff
>> applies to is command line history, so that can of worms is likely to
>> get opened this year. (I should do test.c first...)
> 
> i should probably clarify: mksh is fine as a shell. it just doesn't
> care about cleaning up on exit.

Indeed, but I need toysh anyway.

I don't intend to try to convince android to move off of mksh. I just
hope to provide such a drastically _better_ shell that other people do. :)

I expect it to take awhile, and what I really need are regression tests
against every corner case of both bash and mksh...

>> As for toybox stomping other package's binaries, I'd like it to use
>> --remove-destination but I'm not _quite_ sure that's supported on all
>> the systems it would be installing on? (It's a nonstandard extension. I
>> suppose I could do rm then cp...)

The downside of which is that if you install toybox over itself on a
system that only has toybox when it does an "rm cp" it then won't have a
cp command in the $PATH to put it back.

(Yes, inadvisable to do at the best of times. And admittedly the current
one would fail with "executable busy" if you try to overwrite a running
file, but it wouldn't leave you hosed either...)

Really I'd like to use the "install" command. It's not posix, but won't
stomp hardlinks.

> i think they did that to themselves. looking at their Android.mk,
> they've removed my hard-coded list of symlinks with a call to toybox
> on the host to list all the compiled-in toys. (which is all they
> actually need to build on the Mac.) i don't do this (and don't have
> any intention of doing it) because it's useful to have things in
> toybox without making them directly available. another layer of
> "pending", if you like :-)

I'm promoting three of the commands you _are_ using in pending this
release cycle. Trying to get ahead on that...

Rob