<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 26, 2021 at 10:54 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/26/21 7:35 PM, enh via Toybox wrote:<br>
>     >     Right, you disabled builtins,<br>
>     ><br>
>     > yeah, to try to reduce mksh/toybox confusion. if/when we switch /bin/sh to<br>
>     > toybox it should reduce compat issues too.<br>
<br>
I note that toysh has to call both NOFORK and MAYFORK commands as builtins<br>
anyway. The NOFORKs for obvious reasons (cd in a child process won't help), and<br>
MAYFORK because the behavior changes (kill taking a jobspec argument as well as<br>
a PID, for example).<br>
<br>
But the config option still forces all the rest into seperate processes...<br>
<br>
P.S. A couple MAYFORKS I need to outright cheat for, ala:<br>
<br>
  $ time echo | sleep 3<br>
<br>
  real  0m3.003s<br>
  user  0m0.001s<br>
  sys   0m0.004s<br>
<br>
That's gotta be parsed _before_ the rest of the pipeline, which technically<br>
makes "time" it a flow control statement. Meanwhile, in bash:<br>
<br>
  $ echo | time sleep 3<br>
  bash: time: command not found<br>
<br>
Because of course. (Mine should work called both ways. It's on the todo list...)<br>
<br>
>     Doing so uncovered a legitimate bug (which I've been too buried to address but<br>
>     it's on the todo list) and made me think I might need to run the test suite with<br>
>     every combination of CFG_TOYBOX_* toggled, which is exponentially increasing on<br>
>     the number of options. :(<br>
> <br>
> it's definitely useful to at least test the "all toybox" configuration, since<br>
> that's basically what we test on Android (modulo mksh as the shell). but i catch<br>
> anything like that within a week or so anyway :-)<br>
<br>
Your testing is an excellent crutch, and I'm trying not to rely on it. :)<br>
<br>
>     What stops code from losing track of filehandles and calling close(1) and then<br>
>     opening a new stdout a moment later by accident? I remember segfaulting one of<br>
>     the gnu tools feeding it "-" as an argument more than once (it was a "what<br>
>     happens if" test implementing the toybox version and the answer, as is so often<br>
>     the case, is "nobody in gnu-land ever thought of that or tried it").<br>
> <br>
> fdsan: <a href="https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md</a><br>
<br>
Static tools: meet the halting problem. Halting problem, static tools.<br></blockquote><div><br></div><div>i see you TL;DRed ... fdsan (like all the other *san tools it's named after, despite not actually being related) is a dynamic tool :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>     2) Defers the open() until there's an actual problem. Yes it calls open more<br>
>     than once if it has more than one thing to do (instead of dup) but it's one call<br>
>     made in a loop, and doesn't happen at all in the common case.<br>
> <br>
> yeah, that sounds reasonable. done<br>
> in <a href="https://android-review.googlesource.com/c/platform/bionic/+/1869594" rel="noreferrer" target="_blank">https://android-review.googlesource.com/c/platform/bionic/+/1869594</a><br>
<br>
Yay! Thank you.<br>
<br>
>     So utf8 won't ever work in static bionic the same way DNS queries won't work in<br>
>     static glibc (because that needs to dlopen libnss).<br>
> <br>
> fancy stuff like widths won't work, no.<br>
<br>
Alas width is one of the few things I care about when parsing unicode, because<br>
it's used for text fitting (ps/top display fields and command line editing), and<br>
"is this a combining character or not" is the way to count unicode characters.<br>
(One non-combining codepoint plus five combining codepoints is one character.<br>
I'm still facepalming over the combining characters coming AFTER the character<br>
they combine with so you have to read PAST the end and then ungetc_w() to<br>
accurately delineate. Is there some advantage I'm missing to doing it that way?)<br>
<br>
>     >     Static linking is a legitimate use case. Android does not particularly<br>
>     treat it<br>
>     >     as such, but I'm going to keep periodically tapping the sign.<br>
>     ><br>
>     > it's a legitimate use case _if you're prepared to carry everything around<br>
>     > yourself_. and that is supported --- feel free to build your own icu4c and<br>
>     ship<br>
>     > your own 30MiB data file :-)<br>
> <br>
>     *shrug* Musl seems to do it well enough for me. I admit I'm not a polyglot.<br>
> <br>
> yeah, the libc APIs aren't really useful for any serious i18n work anyway (look<br>
> at the amount of detail lost in the translation from the icu4c API to the<br>
> wcwidth() one, for example).<br>
<br>
I'm not attempting to render them. That's the terminal's problem. I'm just<br>
trying to divide them into chunks I have to either truncate or stick newlines<br>
into. (Which is a hard enough problem on its own...)<br>
<br>
Rich Fellker made an x11 unicode display terminal once upon a time:<br>
<br>
  <a href="http://git.musl-libc.org/cgit/uuterm/" rel="noreferrer" target="_blank">http://git.musl-libc.org/cgit/uuterm/</a><br>
<br>
But I haven't even taught toybox to use the 24 bit color ANSI escapes yet. :)<br>
<br>
>     > yeah, you just need the `ln -s`s.<br>
> <br>
>     The ones under:<br>
> <br>
>         if [ ${TARGET_ARCH} = x86 -o ${TARGET_ARCH} = x86_64 ]; then<br>
> <br>
>     Which apparently don't have a corresponding arm version?<br>
> <br>
> yeah, i don't have an arm host that's faster than a phone anyway.<br>
<br>
Building AOSP on a raspberry pi 4b should be a feasible thing to do?<br>
<br>
  <a href="https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/" rel="noreferrer" target="_blank">https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/</a><br>
<br>
It's 4xSMP@1.5 ghz, can have 8 gigs ram, </blockquote><div><br></div><div>i mean, i love my rpi400, and it's probably the most fun i've had with a computer since the 1980s, but you don't want to build anything significant on it. it's very noticeably an order of magnitude slower than my 10 year old personal x86 laptop.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">and storage shouldn't be an issue<br>
either (Walmart is currently claiming to have a 2TB usb3 stick on sale for $12,<br>
and amazon says a 1TB sd card is $30. Can't vouch for either, but I bought a<br>
512G sd card at Target that works fine so far?)<br></blockquote><div><br></div><div><div>and i'd strongly recommend against doing anything on an sd card --- the few times i've thought i've killed my rpi400 have actually been asking it to do something i/o intensive on an sd card. most of the time you don't notice they're awful, but try something "medium heavy" like checking out the linux kernel onto an sd card and, well, it isn't pretty...</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It would be a "run overnight" kinda thing, but I don't think I've ever<br>
personally owned a system that's _not_ true for...<br></blockquote><div><br></div><div>i hope that's not actually true... even a several year old laptop can build AOSP in a few _hours_. hell, i have a MacBook "Pro" that can build AOSP in a few hours, and between their awful keyboards and their general slowness those things have a special circle in hell reserved just for them!</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>