<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 4, 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 6/4/21 8:22 AM, Dan Brown wrote:<br>
> Hi Rob- thanks. I get the impression that I would not be able to help on the<br>
> things you're working on - they sound like they involve knowledge that is too<br>
> deep for me to learn for a side project.<br>
<br>
That's just what _I'm_ working on. The project has plenty of surface area. Let's<br>
see...<br>
<br>
If somebody wanted to write an awk, I'd thank that person profusely. Android<br>
uses kernighan's original awk:<br>
<br>
  <a href="https://en.wikipedia.org/wiki/AWK#Versions_and_implementations" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/AWK#Versions_and_implementations</a><br>
<br>
But it uses a bespoke bsd license variant<br>
(<a href="https://github.com/onetrueawk/awk/blob/master/LICENSE" rel="noreferrer" target="_blank">https://github.com/onetrueawk/awk/blob/master/LICENSE</a>) and toybox uses a public<br>
domain equivalent license, so I can't take code directly from that. Plus I'm<br>
told it doesn't support utf8:<br>
<br>
  <a href="https://github.com/landley/toybox/issues/67#issuecomment-587347070" rel="noreferrer" target="_blank">https://github.com/landley/toybox/issues/67#issuecomment-587347070</a><br>
<br>
I have the very start of an ar.c that doesn't do anything yet (attached). That's<br>
used not just by builds but inside of debian's package management and a few<br>
other places.<br>
<br>
There's a bunch of stuff in toys/pending/*.c. I got about halfway through<br>
mkdosfs.c before getting pulled away and never getting back to it (attached that<br>
too; turns out you MUST support all the fat12/16/32 variants because it uses the<br>
image size to determine file type. I was vaguely thinking I could make a<br>
genvfatfs.c that worked like an archiver (ala genvfatfs dir | gzip | ssh<br>
remote.sys "cat > img.gz"), and maybe even implement the whole mtools suite).<br>
<br>
The mke2fs.c in pending is also half-finished and I haven't touched that in<br>
YEARS (that I was working on for busybox, and copied what I had over into toybox<br>
but it was at the end of the todo heap, and adding ext3 was just a magic file in<br>
a reserved inode number but since then ext4 happened and I haven't had a chance<br>
to look at that at all)...<br>
<br>
For diff.c I really wanted to do a "patience diff" algorithm implementation, but<br>
got a conventional one submitted instead and never had a chance to wrap my head<br>
around the pro/con of the version they did. I bookmarked an algorithm comparison<br>
article:<br>
<br>
  <a href="https://blog.jcoglan.com/2017/09/19/the-patience-diff-algorithm/" rel="noreferrer" target="_blank">https://blog.jcoglan.com/2017/09/19/the-patience-diff-algorithm/</a><br>
<br>
And have various old bookmarks about patience diff:<br>
<br>
  <a href="https://bramcohen.livejournal.com/37690.html" rel="noreferrer" target="_blank">https://bramcohen.livejournal.com/37690.html</a><br>
  <a href="https://bramcohen.livejournal.com/73318.html" rel="noreferrer" target="_blank">https://bramcohen.livejournal.com/73318.html</a><br>
  <a href="https://en.wikipedia.org/wiki/Patience_sorting" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Patience_sorting</a><br>
<br>
I need to write a less.c (probably using watch.c as a model, and definitely<br>
implementing -R support so colors work). But then I need to do similar code for<br>
the shell's command line editing...<br>
<br>
If somebody who actualy _uses_ modules could review modprobe, that would be<br>
nice. My main blocker there is the embedded systems I put together all have<br>
static kernels.<br>
<br>
I've always been slightly unclear on what getty.c _does_ and why it's separate<br>
from login.c. (Is it related to stty?)<br></blockquote><div><br></div><div>in case i never sent the response to the list, TL;DR "yeah"...</div><div><br></div><div>[i'm told that] if you're using real serial ports, you still need the baud rate setting features. if you're using real serial cables in an electrically noisy environment, you have another local getty patch that i honestly haven't understood well enough to even try to work out whether it makes any sense to upstream :-(</div><div><br></div><div>aiui they were sometimes seeing XOFF sent to init, causing boot to hang. (although i understand that XOFF/XON is useful in theory, i've been disabling it since the early 1990s because i've haven't deliberately used it since the early 1980s when computers were still slow enough for human reaction times to be somewhat meaningful there.)</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">
I want to redo route.c to use the netlink api to add multi-table support (ala<br>
<a href="https://android.googlesource.com/platform/external/toybox/+/48e1f81151f6" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/external/toybox/+/48e1f81151f6</a>).<br>
<br>
> After reading through your state-of-the-toybox message, the commands "tr" and<br>
> "stdbuf" are interesting to me. If you think it is worth a shot for me to give<br>
> it a go, let me know which one you'd recommend.<br>
<br>
It'd be great if somebody could tackle stdbuf, I have no idea how that one<br>
works. (The buffering is in libc, how does one program tell the next executable<br>
to use different libc default parameters? Export an environment variable?</blockquote><div><br></div><div>yes.</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"> Is<br>
doing that portable between glibc/musl/bionic? </blockquote><div><br></div><div>no, glibc-only.</div><div><br></div><div>(i thought we'd already argued that this means you'll have the glibc-provided binary if you're using glibc, which means this doesn't make sense for toybox?)</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">"strings" on the stdbuf binary is<br>
showing _STDBUF_ and LD_PRELOAD and libstdbuf.so and that just sounds ugly...)<br>
<br>
My main todo item on tr is I'd like to have utf8/unicode support, but haven't<br>
figured out how to do so yet at a conceptual level because it's matching a<br>
source string with a destination string by position, and things like [:alnum:]<br>
expand to different numbers of entries in ascii vs unicode. We had a thread on<br>
that here:<br>
<br>
  <a href="http://lists.landley.net/pipermail/toybox-landley.net/2020-December/012158.html" rel="noreferrer" target="_blank">http://lists.landley.net/pipermail/toybox-landley.net/2020-December/012158.html</a><br>
<br>
Rich Felker said he had a simple way to do it, but we've never sat down to have<br>
him explain it to me.<br></blockquote><div><br></div><div>(i'd be curious to hear that, because every implementation i'm aware of -- and the Unicode standard --literally end up with a huge table *and* hard-coded special cases in the code. the closest i've come to "clever" with this was to hoist the hard-coded special cases out and have a separate "easy case" copy of the loop. but that's only a run-time "simplification", and makes the implementation strictly larger.)</div><div><br></div><div>but more than that, i'd still like to hear an argument that trying to be clever here makes any _sense_ :-)</div><div><br></div><div>i'd ask for a single real-world example where someone's actually using this, but since BSD and GNU and Plan 9 trs don't, that doesn't exist.</div><div><br></div><div>(and this ignores the question of "sure, but aren't we going to harm more ASCII-only 'kernel build' users by accidentally taking their locale into account than we are going to help imaginary Turkish AT&T lawyers still using the Unix command line for writing their patent applications in 2021", to which i'm pretty sure the answer is "yes, the only net result of implementing this would be that we'd need to tell a bunch of people to set their locale to "C" for their builds...".)</div><div><br></div><div>fwiw, getting back to something you said earlier, i think *this* is where one true awk "doesn't support utf-8" --- "convert Turkish input to upper/lowercase" _ought_ to be something that awk can do that tr can't (because tr is all about characters/bytes, but awk is all about strings), but one true awk can't do it either. perl and python can. realistically i think anyone who falls into the "no, i really do want to deal with all the weirdness of human scripts [in the Cyrillic/Hangeul sense of the word]" category (a) should use and (b) is already using python anyway. even the kernel and toybox use perl or C where awk would do. "it's POSIX", sure, but "no-one who wasn't doing this kind of thing in the 1990s has ever used it, and those of us who were don't want to write things that only we can maintain".</div><div><br></div><div>your non-POSIX cut(1) extension covers 80% of the in-the-wild use of awk anyway :-) if you still talk to any of the busybox folks, we should suggest they copy that --- it would be nice for it to be a de facto standard so we can get it into POSIX sometime around the 2040s... (and have made lives better for the folks who don't care about standards and just want to "get things done" in the intervening decades!)</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">
> Dan<br>
<br>
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>