From enh at google.com Mon Apr 1 08:31:13 2024 From: enh at google.com (enh) Date: Mon, 1 Apr 2024 08:31:13 -0700 Subject: [Toybox] more gnu nonsense: cp -n Message-ID: hadn't seen this one before... cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead (consider me skeptical that a system without -n is going to have --update=none...) From aquahobbyist at proton.me Mon Apr 1 08:56:58 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 01 Apr 2024 15:56:58 +0000 Subject: [Toybox] more gnu nonsense: cp -n In-Reply-To: References: Message-ID: On Mon, Apr 1, 2024 at 10:31, enh via Toybox <[toybox at lists.landley.net](mailto:On Mon, Apr 1, 2024 at 10:31, enh via Toybox < wrote: > hadn't seen this one before... > > cp: warning: behavior of -n is non-portable Really? Having ?Warn if GNU extensions? flags is one thing, doing it by default is? > and may change in future; > use --update=none instead > > (consider me skeptical that a system without -n is going to have > --update=none?) I?ve yet to find any utility set other than GNU with cp ?update, FreeBSD and toybox have a -n, but no one bothered to do ?update. But sure, that?s more portable. The GNU project ?removing bloat? by deprecating extensions would be nice? if they weren?t removing things people actually use. Instead of actual bloat (_gawk_ has namespace control and a -M option to make the math arbitrary precision, along with a million other things no one has ever used) - Oliver Webb -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Mon Apr 1 22:18:03 2024 From: rob at landley.net (Rob Landley) Date: Tue, 2 Apr 2024 00:18:03 -0500 Subject: [Toybox] more gnu nonsense: cp -n In-Reply-To: References: Message-ID: On 4/1/24 10:31, enh via Toybox wrote: > hadn't seen this one before... > > cp: warning: behavior of -n is non-portable and may change in future; > use --update=none instead > > (consider me skeptical that a system without -n is going to have > --update=none...) Define non-portable? Freebsd 14 has -n, macos has -n, busybox cp has -n, and of course toybox (and thus android) has -n. Meanwhile: $ ./busybox cp --update=none one two cp: option '--update' doesn't allow an argument root at freebsd:~ # cp --update=none one two cp: illegal option -- - root at freebsd:~ # cp --update=none one two cp: illegal option -- - $ toybox cp --update=none one two cp: Unknown option 'update=none' (see "cp --help") Those clowns are explicitly advocating for a LESS portable option. This is why I'm not removing "egrep", which is a shell wrapper on my devuan system by the way: $ which egrep /bin/egrep $ cat /bin/egrep #!/bin/sh exec grep -E "$@" At least THAT one is easy for distributions to keep doing regardless of gnu/stupid. If the solution for cp -n isn't "distro patches out the stupid", then "install busybox cp" or just "use alpine". Spurious warnings from gnu are just that: spurious. Rob From rprichard at google.com Mon Apr 1 23:35:18 2024 From: rprichard at google.com (Ryan Prichard) Date: Mon, 1 Apr 2024 23:35:18 -0700 Subject: [Toybox] more gnu nonsense: cp -n In-Reply-To: References:

Message-ID: Apparently upstream coreutils "cp -n" changed between 9.1 and 9.2, and the Debian maintainers reverted the change temporarily(?) and also added the "non-portable" error. In coreutils 9.1 and older, "cp -n" quietly skipped a file if the destination existed, but as of 9.2, it instead prints an error and exits with non-zero at the end. (I saw some stuff about "immediately failing" on the Debian bug, but AFAICT, cp keeps going and fails at the end.) It does look like the new 9.2+ behavior matches "cp -n" on macOS (14.3.1) (and probably FreeBSD but I didn't test that). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058752 Someone complained to upstream, but it didn't go anywhere: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572 New behavior: $ docker run -it fedora:39 bash -l [root at 137183bb9d76 /]# cp --version | head -n1 cp (GNU coreutils) 9.3 [root at 137183bb9d76 /]# mkdir a b; touch a/x a/y [root at 137183bb9d76 /]# cp -rnv a b; echo $? 'a' -> 'b/a' 'a/x' -> 'b/a/x' 'a/y' -> 'b/a/y' 0 [root at 137183bb9d76 /]# cp -rnv a b; echo $? cp: not replacing 'b/a/x' cp: not replacing 'b/a/y' 1 [root at 137183bb9d76 /]# rm -f b/a/x; cp -rnv a b; echo $?; ls b/a 'a/x' -> 'b/a/x' cp: not replacing 'b/a/y' 1 x y [root at 137183bb9d76 /]# rm -f b/a/y; cp -rnv a b; echo $?; ls b/a cp: not replacing 'b/a/x' 'a/y' -> 'b/a/y' 1 x y Old behavior: $ docker run -it fedora:38 bash -l [root at e296da330d05 /]# cp --version | head -n1 cp (GNU coreutils) 9.1 [root at e296da330d05 /]# mkdir a b; touch a/x a/y [root at e296da330d05 /]# cp -rnv a b; echo $? 'a' -> 'b/a' 'a/x' -> 'b/a/x' 'a/y' -> 'b/a/y' 0 [root at e296da330d05 /]# cp -rnv a b; echo $? 0 -Ryan On Mon, Apr 1, 2024 at 10:09?PM Rob Landley wrote: > On 4/1/24 10:31, enh via Toybox wrote: > > hadn't seen this one before... > > > > cp: warning: behavior of -n is non-portable and may change in future; > > use --update=none instead > > > > (consider me skeptical that a system without -n is going to have > > --update=none...) > > Define non-portable? Freebsd 14 has -n, macos has -n, busybox cp has -n, > and of > course toybox (and thus android) has -n. > > Meanwhile: > > $ ./busybox cp --update=none one two > cp: option '--update' doesn't allow an argument > root at freebsd:~ # cp --update=none one two > cp: illegal option -- - > root at freebsd:~ # cp --update=none one two > cp: illegal option -- - > $ toybox cp --update=none one two > cp: Unknown option 'update=none' (see "cp --help") > > Those clowns are explicitly advocating for a LESS portable option. > > This is why I'm not removing "egrep", which is a shell wrapper on my devuan > system by the way: > > $ which egrep > /bin/egrep > $ cat /bin/egrep > #!/bin/sh > exec grep -E "$@" > > At least THAT one is easy for distributions to keep doing regardless of > gnu/stupid. > > If the solution for cp -n isn't "distro patches out the stupid", then > "install > busybox cp" or just "use alpine". Spurious warnings from gnu are just that: > spurious. > > Rob > _______________________________________________ > Toybox mailing list > Toybox at lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Wed Apr 3 03:13:39 2024 From: rob at landley.net (Rob Landley) Date: Wed, 3 Apr 2024 05:13:39 -0500 Subject: [Toybox] more gnu nonsense: cp -n In-Reply-To: References:

wrote: > These seem to be easier to work with than things like the concatenated file decoder > since the BCJ decoders are just functions you can drop into code and they work in a > very modular manner. > > 255 bytes in bloatcheck, tested and works on linux-kernel tarballs. > > - Oliver Webb -------------- next part -------------- An HTML attachment was scrubbed... URL: From enh at google.com Mon Apr 8 09:01:43 2024 From: enh at google.com (enh) Date: Mon, 8 Apr 2024 09:01:43 -0700 Subject: [Toybox] utf8towc(), stop being defective on null bytes In-Reply-To: References: <29af44c8-d5b3-7175-fa95-d286bf88c579@landley.net> Message-ID: On Sun, Apr 7, 2024 at 7:43?AM Oliver Webb via Toybox wrote: > > On Sunday, April 7th, 2024 at 03:54, Rob Landley wrote: > > > As for moving it again someday, unnecessarily moving files is churn that makes > > the history harder to see, and lib/*.c has never been a strict division (more > > "one giant file seems a bit much"). The basic conversion to/from utf8 is > > different from caring about the characteristics of unicode code points (which > > the rest of utf8.c does), so having it in lib.c makes a certain amount of sense, > > and I'm not strongly motivated to change it without a good reason. > > > > It might happen eventually because I'm still not happy with the general unicode > > handling design "yet", but that's a larger story. > > Eh, they're utf8 functions, utf8 functions being in the file named "utf8.c" makes > more sense from my perspective. > > I was also planning on doing some form of a documentation write up in code.html > about, among other things, the utf8 functions. That stopped when I realized > that would mean documenting all of the eighty-something functions in lib.c. > > > (I probably should have called it unicode.c instead, but > > unicode is icky, the name is longer, and half the unicode stuff is still in libc > > anyway). > > > > Unicode is icky because utf8 and unicode are not the same thing. > > If it's handling unicode instead of utf8 and the 2 are noticeably different, > I don't see why a file for unicode stuff should be called utf8.c. > > > Because Microsoft broke utf8 in multiple ways through the unicode consortium, > > among other things making 4 bytes the max: > > I have to ask, if you disagree with the decision to cap utf8 to only a million codepoints, > and not complying with that only means that anyone who wants to pass unicode codepoints over > U+10FFFF to toybox code will be able to. Why have code make sure we comply with an insane > microsoft decision when we don't (I don't think?) have to: > > // Limit unicode so it can't encode anything UTF-16 can't. > if (result>0x10ffff || (result>=0xd800 && result<=0xdfff)) return -1; > > > > Another thing I noticed is that if you pass a null byte into utf8towc(), it will > > > assign, but will not "return bytes read" like it's supposed to, instead it will > > > return 0 when it reads 1 byte. > > > > The same way strlen() doesn't include the null terminator in the length "like > > it's supposed to"? Obviously stpcpy() is defective to write a null terminator > > and then return a pointer to that null terminator, instead of returning the > > first byte it didn't modify "like it's supposed to"... > > > > An assertion is not the same as a question. > > If I'm going my the comment over the function body ("This returns bytes read unless error"), > then yes, that is what "it's supposed to do", we have read one byte of input, and written it > successfully to our return destination. A special case for null bytes is fine, but to save > me and any other person that debugging nightmare when they try to do utf8 processing on data > with null bytes in it. I'd prefer if that was mentioned somewhere. > > A bug only becomes a feature when you declare it is, and "undocumented special case" > is another way to say "landmine". > > > Returning length 0 means we hit a null terminator, > > Null bytes aren't always "terminators". You can embed null bytes into data and still > want to do utf8 processing with it. that's questionable ... the desire to have ASCII NUL in utf-8 sequences (without breaking the "utf-8 sequences are usable as c strings" property) is the main reason for the existence of "modified utf-8". > > due to the maximum possible value being truncated BY MICROSOFT so it doesn't outshine their horrible legacy format: > > "BY MICROSOFT", and by you. https://github.com/landley/toybox/blob/master/lib/lib.c#L189. > Do we need to do that for any reason other then to comply to microsoft and the unicode commite? > The linux kernel is agnostic to filenames having "good utf8". Should utf8towc (I don't think > wctoutf8 has this restriction) be agnostic towards "good unicode" when it's utf8 we are processing, > and delegate that job to the fontmetrics code? Again, it's utf8 we are handling with these, > not unicode, even if the 2 are linked. > > "And even then it might be the wrong thing to disallow clever > people from doing clever things. Encoding other information in filenames > might be proper for a number of applications." > - Linus Torvalds, https://yarchive.net/comp/linux/utf8.html > > - Oliver Webb > > _______________________________________________ > Toybox mailing list > Toybox at lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net From enh at google.com Mon Apr 8 09:14:30 2024 From: enh at google.com (enh) Date: Mon, 8 Apr 2024 09:14:30 -0700 Subject: [Toybox] tail test failures? Message-ID: looks like the github CI has been red for ubuntu and macOS since april 5th? this revert fixes the current failing test: [master 8368f8f9] Revert "Enforce min/max for % input type (time in seconds w/millisecond granularity)." but that just gets me a different failing test, so it's obviously a bit more subtle than that :-) From rob at landley.net Mon Apr 8 09:57:42 2024 From: rob at landley.net (Rob Landley) Date: Mon, 8 Apr 2024 11:57:42 -0500 Subject: [Toybox] utf8towc(), stop being defective on null bytes In-Reply-To: References: <29af44c8-d5b3-7175-fa95-d286bf88c579@landley.net> Message-ID: <7d26f4c1-2b52-84a9-6b7c-2f3f8230e229@landley.net> On 4/8/24 11:01, enh wrote: >> > Returning length 0 means we hit a null terminator, >> >> Null bytes aren't always "terminators". You can embed null bytes into data and still >> want to do utf8 processing with it. > > that's questionable ... the desire to have ASCII NUL in utf-8 > sequences (without breaking the "utf-8 sequences are usable as c > strings" property) is the main reason for the existence of "modified > utf-8". You don't need a conversion function to grab a nul byte, you can check if it's a null byte. That value _is_ a special case, the enclosing loop can deal with it easily enough (there's nothing to convert, it's a NUL byte, check directly). I've got functions like regexec0() that work over a range instead of using a NUL, and those have to deal with libc's regex stopping at NUL so the enclosing loop advances past it and restarts. Rob From aquahobbyist at proton.me Mon Apr 8 09:53:03 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 08 Apr 2024 16:53:03 +0000 Subject: [Toybox] utf8towc(), stop being defective on null bytes In-Reply-To: References: <29af44c8-d5b3-7175-fa95-d286bf88c579@landley.net> Message-ID: >> Null bytes aren't always "terminators". You can embed null bytes into data and still >> want to do utf8 processing with it. > > that's questionable ... the desire to have ASCII NUL in utf-8 > sequences (without breaking the "utf-8 sequences are usable as c > strings" property) is the main reason for the existence of "modified > utf-8". Admittedly, that?s the first time I?ve heard of "modified utf-8". There seems to be different flavors for every language (the Java one seems to be the most prominent) which means not everyone is gonna use it. Because there is no standard Still, U+0000 is a valid code point, and having a special case especially for it that isn?t mentioned but you have to watch out for is either a bug or a documentation error. ? Oliver Webb -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Mon Apr 8 10:08:26 2024 From: rob at landley.net (Rob Landley) Date: Mon, 8 Apr 2024 12:08:26 -0500 Subject: [Toybox] utf8towc(), stop being defective on null bytes In-Reply-To: References: <29af44c8-d5b3-7175-fa95-d286bf88c579@landley.net>

Message-ID: On 4/8/24 11:53, Oliver Webb wrote: > Still, U+0000 is a valid code point, and having a special case especially for it > that isn?t mentioned but you have to watch out for is either a bug or a > documentation error. I say it's intentional, you reassert that I'm wrong. I'll leave you to your opinion... Rob From aquahobbyist at proton.me Mon Apr 8 10:22:11 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 08 Apr 2024 17:22:11 +0000 Subject: [Toybox] utf8towc(), stop being defective on null bytes In-Reply-To: References: <29af44c8-d5b3-7175-fa95-d286bf88c579@landley.net>

Message-ID: On Mon, Apr 8, 2024 at 12:00, Rob Landley <[rob at landley.net](mailto:On Mon, Apr 8, 2024 at 12:00, Rob Landley <

wrote: > On 4/8/24 11:53, Oliver Webb wrote: >> Still, U+0000 is a valid code point, and having a special case especially for it >> that isn?t mentioned but you have to watch out for is either a bug or a >> documentation error. > > I say it's intentional, you reassert that I'm wrong. this is at least the 4th time I said ?if you want that behavior, that?s fine? but can we at least document the Landmine so no one steps on it? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Mon Apr 8 11:34:20 2024 From: rob at landley.net (Rob Landley) Date: Mon, 8 Apr 2024 13:34:20 -0500 Subject: [Toybox] tail test failures? In-Reply-To: References: Message-ID: <0383cb02-33fa-35eb-8953-4cfa0aefc7e0@landley.net> On 4/8/24 11:14, enh via Toybox wrote: > looks like the github CI has been red for ubuntu and macOS since april 5th? > > this revert fixes the current failing test: > > [master 8368f8f9] Revert "Enforce min/max for % input type (time in > seconds w/millisecond granularity)." > > but that just gets me a different failing test, so it's obviously a > bit more subtle than that :-) Darn it, didn't get a release out on leap day, didn't get a release out during the eclipse... Always one more thing. (Pay no attention to the binaries I just uploaded, gotta rebuild them and do it again. This is why I push the tag and update the news.html file on the website LAST...) Rob From aquahobbyist at proton.me Mon Apr 8 12:20:24 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 08 Apr 2024 19:20:24 +0000 Subject: [Toybox] prereq build, what is the motivation behind building od? Message-ID: Although I may be wrong, "od" doesn?t seem to be in the build infrastructure. What?s the reason for it being a "prereq" command. Also, have you thought about specifying FILES through the command line to reduce build time by only building what we need to. Scanning for commands with ?which? and maybe uname for stuff like gsed and putting them in FILES if we don?t have a good enough version. Then generating generated/ files based off of that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From enh at google.com Mon Apr 8 13:28:18 2024 From: enh at google.com (enh) Date: Mon, 8 Apr 2024 13:28:18 -0700 Subject: [Toybox] [PATCH] timeout.test: reduce flake. Message-ID: A (presumably overloaded) CI server saw the `exit 0` test time out. Given that several of these tests should just fail immediately, having a huge timeout isn't even a bad thing --- if we had a bug that caused us to report the correct status, but not until the timeout had _also_ expired, this would make that failure glaringly obvious. Aren't the other tests with 0.1s timeouts potentially flaky? Yes, obviously, but I'll worry about those if/when we see them in real life? (Because increasing those timeouts _would_ increase overall test time.) --- tests/timeout.test | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-timeout.test-reduce-flake.patch Type: application/octet-stream Size: 2093 bytes Desc: not available URL: From aquahobbyist at proton.me Mon Apr 8 16:45:14 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 08 Apr 2024 23:45:14 +0000 Subject: [Toybox] utf8towc(), stop being defective on null bytes ([PATCH]) Message-ID: On Monday, April 8th, 2024 at 12:22, Oliver Webb via Toybox wrote: > On Mon, Apr 8, 2024 at 12:00, Rob Landley wrote: > > > On 4/8/24 11:53, Oliver Webb wrote: > > > Still, U+0000 is a valid code point, and having a special case especially for it > > > that isn?t mentioned but you have to watch out for is either a bug or a > > > documentation error. > > > > I say it's intentional, you reassert that I'm wrong. > > this is at least the 4th time I said ?if you want that behavior, that?s fine? but can we at least document the Landmine so no one steps on it? > > ? Since apparently this isn't a bug, can we at least update the comment to match the code. (This is the solution I was implying when I said "or a documentation error", and "A special case for null bytes is fine, but to save me and any other person that debugging nightmare when they try to do utf8 processing on data with null bytes in it. I'd prefer if that was mentioned somewhere." in the email you didn't read ("What's context needed for?")) Attached... - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-comment-in-utf8towc-to-match-what-code-is-doi.patch Type: text/x-patch Size: 780 bytes Desc: not available URL: From rob at landley.net Mon Apr 8 18:58:47 2024 From: rob at landley.net (Rob Landley) Date: Mon, 8 Apr 2024 20:58:47 -0500 Subject: [Toybox] Release 0.8.11 is out. Message-ID: <77be38fd-cedc-30c4-1d5c-a5ac68f178f5@landley.net> Yeah, a bit overdue. Lemme know if anything in the release notes isn't clear. Still doing a texas linuxfest talk soonish. Hopefully they post a video eventually... Rob From aquahobbyist at proton.me Mon Apr 8 18:57:25 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Tue, 09 Apr 2024 01:57:25 +0000 Subject: [Toybox] Release 0.8.11 is out. In-Reply-To: <77be38fd-cedc-30c4-1d5c-a5ac68f178f5@landley.net> References: <77be38fd-cedc-30c4-1d5c-a5ac68f178f5@landley.net> Message-ID: <5Z7LIaFmpOTAYSJfgxE0hTbeee5O0dHA4Iod51MzF2vokzr6DzGwNa8NKDrQvrNsbkViSp-hmrTDGk-j7kAZddnhIUXunOHJ26mPCE_HwGo=@proton.me> On Monday, April 8th, 2024 at 20:49, Rob Landley wrote: > Yeah, a bit overdue. Lemme know if anything in the release notes isn't clear. The quickstart webpage seems to go to a 404, have you synced it? - Oliver Webb From aquahobbyist at proton.me Mon Apr 8 19:02:08 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Tue, 09 Apr 2024 02:02:08 +0000 Subject: [Toybox] Release 0.8.11 is out. In-Reply-To: <5Z7LIaFmpOTAYSJfgxE0hTbeee5O0dHA4Iod51MzF2vokzr6DzGwNa8NKDrQvrNsbkViSp-hmrTDGk-j7kAZddnhIUXunOHJ26mPCE_HwGo=@proton.me> References: <77be38fd-cedc-30c4-1d5c-a5ac68f178f5@landley.net> <5Z7LIaFmpOTAYSJfgxE0hTbeee5O0dHA4Iod51MzF2vokzr6DzGwNa8NKDrQvrNsbkViSp-hmrTDGk-j7kAZddnhIUXunOHJ26mPCE_HwGo=@proton.me> Message-ID: On Monday, April 8th, 2024 at 20:57, Oliver Webb via Toybox wrote: > On Monday, April 8th, 2024 at 20:49, Rob Landley rob at landley.net wrote: > > > Yeah, a bit overdue. Lemme know if anything in the release notes isn't clear. > > > The quickstart webpage seems to go to a 404, have you synced it? (The one in the release notes (quickstart.html), not the one in the nav headers (quick.html), which makes it seem more like a mistyped link than a unsynced page) - Oliver Webb aquahobbyist at proton.me From aquahobbyist at proton.me Mon Apr 8 20:49:18 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Tue, 09 Apr 2024 03:49:18 +0000 Subject: [Toybox] [PATCH] ip.c: addr by default? Fix "make ipaddr" breaks due to no config symbols Message-ID: Since someone made a github issue requesting ip, I took a closer look at ip.c The first thing I noticed is that "ip" with no args returns usage text instead of help text (Like sed did before that got fixed some time months ago) or defaulting to "ip addr" (Which is what ip usually does). Not a big issue, but still it'd be nice to have that since non-toybox ip does "ip addr" on no args. The second issue is that "make ipaddr" breaks because of a compiler error in scripts/install.c when trying to include generated/newtoys.h for "help_data". Which is weird, but it's due to multiple OLDTOYS using the same USE_ macro. They need their own USE_ macros and config symbols like {e,f}grep if they should be build-able as individual sub-commands. (Unlike {e,f}grep, they should default to "n" so they don't get included on a build of ip) Attached is a patch which fixes "make ipsubcmd" - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ip.c-Give-subcommands-their-own-config-symbols-so-th.patch Type: text/x-patch Size: 1546 bytes Desc: not available URL: From aquahobbyist at proton.me Tue Apr 9 14:54:15 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Tue, 09 Apr 2024 21:54:15 +0000 Subject: [Toybox] [PATCH] nuke wcrtomb() Message-ID: <6MIoSs6iWOyPYzorGMgnY0gdv9JiS_NX5rGK3gI-VUWrothMaRytVzbseP53K4C10jIZ75ynbJ9bkXYWdUjafed9KyG49kaf4suPZeN8tzk=@proton.me> Not pulling in 2 localization functions (One from libc, one from lib.c) reduces executable size, also more portable on glibc systems because locale installation nonsense. No typecasting to int's either. 15 bytes saved in bloatcheck. tests pass for everything with changes applied (Except the shell). - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Nuke-wcrtomb-since-we-have-our-own-wctoutf8.patch Type: text/x-patch Size: 2817 bytes Desc: not available URL: From aquahobbyist at proton.me Wed Apr 10 22:59:11 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Thu, 11 Apr 2024 05:59:11 +0000 Subject: [Toybox] [PATCH] fix single command builds by adding config symbols Message-ID: Found out about "make change" and decided to run it to see which commands break. The "make ipaddr" issue addressed in a previous thread is present on ping6, nc, halt, poweroff, and prlimit ('[' also experiences this but didn't fix it in this patch). The solution is the same too, different USE_ macros and more config symbols. An exception to this is wget, which fails for a different reason I've yet to diagnose properly: wget:generated/{Config.in,newtoys.h,flags.h,tags.h,help.h} Compile change/wget ........Assembler messages: Fatal error: can't create generated/obj/lib_env.o: No such file or directory Assembler messages: Fatal error: can't create generated/obj/lib_hash.o: No such file or directory Assembler messages: Fatal error: can't create generated/obj/lib_lib.o: No such file or directory - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-single-command-builds-for-nc-ping6-halt-poweroff.patch Type: text/x-patch Size: 3754 bytes Desc: not available URL: From jmakip87 at gmail.com Thu Apr 11 01:37:16 2024 From: jmakip87 at gmail.com (=?UTF-8?B?SmFybm8gTcOka2lww6TDpA==?=) Date: Thu, 11 Apr 2024 11:37:16 +0300 Subject: [Toybox] [PATCH] nuke wcrtomb() In-Reply-To: <6MIoSs6iWOyPYzorGMgnY0gdv9JiS_NX5rGK3gI-VUWrothMaRytVzbseP53K4C10jIZ75ynbJ9bkXYWdUjafed9KyG49kaf4suPZeN8tzk=@proton.me> References: <6MIoSs6iWOyPYzorGMgnY0gdv9JiS_NX5rGK3gI-VUWrothMaRytVzbseP53K4C10jIZ75ynbJ9bkXYWdUjafed9KyG49kaf4suPZeN8tzk=@proton.me> Message-ID: there is slight difference between wctoutf8 and wcrtomb, wcrtomb returns -1 if its presented with non valid char, of its char is not presentable on current locale. I think wctoutf8 only returns positive integers. so your patch to strlower for example might introduce unreachable code path. diff --git a/lib/lib.c b/lib/lib.c index 6a4a77dd..79ae2a1d 100644 --- a/lib/lib.c +++ b/lib/lib.c @@ -426,7 +426,7 @@ char *strlower(char *s) // if we had a valid utf8 sequence, convert it to lower case, and can't // encode back to utf8, something is wrong with your libc. But just // in case somebody finds an exploit... - len = wcrtomb(new, c, 0); + len = wctoutf8(new, c); if (len < 1) error_exit("bad utf8 %x", (int)c); new += len; On Wed, Apr 10, 2024 at 12:54?AM Oliver Webb via Toybox wrote: > > Not pulling in 2 localization functions (One from libc, one from lib.c) reduces executable > size, also more portable on glibc systems because locale installation nonsense. No > typecasting to int's either. > > 15 bytes saved in bloatcheck. tests pass for everything with changes applied (Except the shell). > > - Oliver Webb > _______________________________________________ > Toybox mailing list > Toybox at lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net -Jarno From aquahobbyist at proton.me Thu Apr 11 08:46:51 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Thu, 11 Apr 2024 15:46:51 +0000 Subject: [Toybox] [PATCH] nuke wcrtomb() In-Reply-To: References: <6MIoSs6iWOyPYzorGMgnY0gdv9JiS_NX5rGK3gI-VUWrothMaRytVzbseP53K4C10jIZ75ynbJ9bkXYWdUjafed9KyG49kaf4suPZeN8tzk=@proton.me> Message-ID: On Thu, Apr 11, 2024 at 03:37, Jarno M?kip?? wrote: > there is slight difference between wctoutf8 and wcrtomb, wcrtomb > returns -1 if its presented with non valid char, of its char is not > presentable on current locale. I think wctoutf8 only returns positive > integers. wctouf8 cannot fail because it writes invalid Unicode code points as utf8. This is another reason I asked if we could delegate the job of "Is this a valid Unicode code point" to the other Unicode code. We are not reading Unicode with utf8towc, we are reading utf8, if unicode ever gets replaced, it?s not hard to imagine that new/different encoding system representing itself with utf8 (a very elegant, efficient way to represent this type of stuff). As long as there isn?t a security problem to it, it only makes the code less agnostic where it doesn?t really need to be. I remember from testing if you pass in max unsigned int to wctoutf8, it will write one 0xff character, which is actual invalid utf8 (the theoretical max codepoint in utf8 is 2^31-1). This is a situation where bounds checking seems sane, maybe a "if (wc > 1<<31-1) return -1" at the start of wctoutf8 would fix it? - Oliver Webb -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Fri Apr 12 10:03:49 2024 From: rob at landley.net (Rob Landley) Date: Fri, 12 Apr 2024 12:03:49 -0500 Subject: [Toybox] [PATCH] timeout.test: reduce flake. In-Reply-To: References: Message-ID: Catching up. (I let stuff pile up preparing for the release and then took a couple days off, and now I'm at texas linuxfest doing sleep deprived talk prep for tomorrow...) On 4/8/24 15:28, enh via Toybox wrote: > A (presumably overloaded) CI server saw the `exit 0` test time out. > Given that several of these tests should just fail immediately, > having a huge timeout isn't even a bad thing --- if we had a bug > that caused us to report the correct status, but not until the > timeout had _also_ expired, this would make that failure glaringly > obvious. > > Aren't the other tests with 0.1s timeouts potentially flaky? Yes, > obviously, but I'll worry about those if/when we see them in real > life? (Because increasing those timeouts _would_ increase overall > test time.) Yes it should never happen, but 11 minutes seems like a footgun. I bumped it up to 1 second (10 times as long as before). If you see it again I can bump it to 5 seconds, but much beyond 1 second and the "timeout -v .1 sleep 3" test later on gets flaky, as does: toyonly testcmd "-i" \ "-i 1 sh -c 'for i in .25 .50 2; do sleep \$i; echo hello; done'" \ "hello\nhello\n" "" "" Rob From rob at landley.net Fri Apr 12 10:16:58 2024 From: rob at landley.net (Rob Landley) Date: Fri, 12 Apr 2024 12:16:58 -0500 Subject: [Toybox] prereq build, what is the motivation behind building od? In-Reply-To: References: Message-ID: <553d77e3-9485-4ffb-02b9-acdc3ffb85a8@landley.net> On 4/8/24 14:20, Oliver Webb via Toybox wrote: > Although I may be wrong, "od" doesn?t seem to be in? > the build infrastructure. What?s the reason for it being a > "prereq" command. $ vi scripts/recreate-prereq.sh ... $ grep '^od ' log.txt od "-Anone" "-vtx1" https://github.com/landley/toybox/blob/0.8.11/scripts/make.sh#L230 > Also, have you thought about specifying FILES through > the command line to reduce build time by only building what we need to. Have I thought about micromanaging the build in a way that may not link in combination with a given set of generated/*.h files? Probably at some point. Keep in mind I've been doing this stuff on and off since... depending on how you want to look at it, 1999. > Scanning > for commands with ?which? "which" looks at what's installed on the host out of the $PATH. what does that have to do with what's configured in toybox? (If I supplied an airlock I specified the $PATH...) > and maybe uname for stuff like gsed You mean use uname to figure out if we're running on MacOS or FreeBSD like the code already does in scripts/portability.sh? > and putting them > in FILES if we don?t have a good enough version. I built defconfig under record-commands, and then did the standard "awk '{print $1}' | sort -u | xargs" trick from literally _decades_ ago: https://github.com/landley/aboriginal/blob/dbd0349d8ae6/sources/toys/report_recorded_commands.sh#L10 https://landley.net/aboriginal/FAQ.html#:~:text=logging%20wrapper to get a list of the commands used by that, and used that to generate a toybox .config file enabling those commands. I then made a SHELL SCRIPT that DID ALL THAT so you could SEE HOW/WHY IT WAS BUILT (and also so I could automate updating it, yes I should probably add it to release.txt): https://github.com/landley/toybox/blob/master/scripts/recreate-prereq.sh And tried to explain that I'd done so: https://github.com/landley/toybox/commit/d1acc6e88be5 And how to use the result: https://github.com/landley/toybox/commit/3bbc31c78b41 > Then generating generated/ > files based off of that? No. Rob From enh at google.com Fri Apr 12 10:29:05 2024 From: enh at google.com (enh) Date: Fri, 12 Apr 2024 10:29:05 -0700 Subject: [Toybox] [PATCH] timeout.test: reduce flake. In-Reply-To: References:

Message-ID: no hurry... it's taken us this long to spot any flake, so it'll probably be as long again before we see it again even if we do nothing! On Fri, Apr 12, 2024, 09:54 Rob Landley wrote: > Catching up. (I let stuff pile up preparing for the release and then took a > couple days off, and now I'm at texas linuxfest doing sleep deprived talk > prep > for tomorrow...) > > On 4/8/24 15:28, enh via Toybox wrote: > > A (presumably overloaded) CI server saw the `exit 0` test time out. > > Given that several of these tests should just fail immediately, > > having a huge timeout isn't even a bad thing --- if we had a bug > > that caused us to report the correct status, but not until the > > timeout had _also_ expired, this would make that failure glaringly > > obvious. > > > > Aren't the other tests with 0.1s timeouts potentially flaky? Yes, > > obviously, but I'll worry about those if/when we see them in real > > life? (Because increasing those timeouts _would_ increase overall > > test time.) > > Yes it should never happen, but 11 minutes seems like a footgun. > > I bumped it up to 1 second (10 times as long as before). If you see it > again I > can bump it to 5 seconds, but much beyond 1 second and the "timeout -v .1 > sleep > 3" test later on gets flaky, as does: > > toyonly testcmd "-i" \ > "-i 1 sh -c 'for i in .25 .50 2; do sleep \$i; echo hello; done'" \ > "hello\nhello\n" "" "" > > Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enh at google.com Fri Apr 12 11:24:08 2024 From: enh at google.com (enh) Date: Fri, 12 Apr 2024 11:24:08 -0700 Subject: [Toybox] today in "shut up, gnu!" Message-ID: ~/aosp-main-with-phones$ find external/ -name NOTICE -type l -maxdepth 2 find: warning: you have specified the global option -maxdepth after the argument -name, but global options are not positional, i.e., -maxdepth affects tests specified before it as well as those specified after it. Please specify global options before other arguments. (it does do the right thing, but insists on whining first.) From vidar at karlsen.tech Sat Apr 13 01:00:44 2024 From: vidar at karlsen.tech (Vidar Karlsen) Date: Sat, 13 Apr 2024 10:00:44 +0200 Subject: [Toybox] uname no longer broken on FreeBSD? Message-ID: Hello, toys/posix/uname.c builds and runs on Freebsd now. I have tested it on 13.2-amd64, 14.0-amd64, 13.2-arm64 and 14.0-arm64. I think it's safe to put CONFIG_UNAME=y back into kconfig/freebsd_miniconfig. From rob at landley.net Sat Apr 13 05:13:11 2024 From: rob at landley.net (Rob Landley) Date: Sat, 13 Apr 2024 07:13:11 -0500 Subject: [Toybox] uname no longer broken on FreeBSD? In-Reply-To: References: Message-ID: On 4/13/24 03:00, Vidar Karlsen via Toybox wrote: > Hello, > > toys/posix/uname.c builds and runs on Freebsd now. I have tested it on > 13.2-amd64, 14.0-amd64, 13.2-arm64 and 14.0-arm64. I think it's safe to > put CONFIG_UNAME=y back into kconfig/freebsd_miniconfig. Ah, commit d2bada0e42e6 fixed it but I only remembered to add it to macos_defconfig, forgot the other one. Thanks, Rob From rob at landley.net Sat Apr 13 07:43:29 2024 From: rob at landley.net (Rob Landley) Date: Sat, 13 Apr 2024 09:43:29 -0500 Subject: [Toybox] today in "shut up, gnu!" In-Reply-To: References: Message-ID: <60de25d6-0fae-036c-0ab2-8648ccb6578f@landley.net> On 4/12/24 13:24, enh via Toybox wrote: > ~/aosp-main-with-phones$ find external/ -name NOTICE -type l -maxdepth 2 > find: warning: you have specified the global option -maxdepth after > the argument -name, but global options are not positional, i.e., > -maxdepth affects tests specified before it as well as those specified > after it. Please specify global options before other arguments. > > (it does do the right thing, but insists on whining first.) I've hit that too, and am big into Not Doing That. Thought I'd blogged about it, but it could have been irc, or twitter (which I deleted when twitler bought it but have an archive I should probably post somewhere), or... probably too old for mastodon? There's a reason I get so exasperated about each new gnu/nag I stub my toe on. It's gone beyond isolated incident into "pattern of looking down on everyone else and sneering". Unix has always been a silent protagonist, without which shell scripts are a pain to do. If it doesn't work, they'll figure out why. Just behave consistently (according to SOME kind of understandable logic) and let them keep the pieces. Sometimes there's a -v flag to activate printfs() stuck into the code, but don't express opinions when they didn't ASK. (Put them in the man page or --help if it's that important.) This has ALWAYS been the unix way. There are ALWAYS corner cases, and deterministic behavior is not difficult to debug. The gnu/FSF never got that. Stallman only decamped to unix under protest, a refugee from the Jupiter project's collapse orphaning ITS, and he never really understood it. RMS did not INVENT the idea of cloning unix with his big announcement in 1983. Unix was a diverse community starting from the 1974 ACM article, let alone the Berkeley Software Distribution in 1975. The first full from-scratch Unix clone (writing their own kernel, compiler, and command line) was Coherent, which shipped in 1980. Paul Allen copied subdirectories and file descriptors from unix into DOS 2.0 not long after. Minix started in 1983 and shipped in 1986, and Linux is 100% a descendant of Minix (developed on minix, its first filesystem was minix, the development discussion on comp.os.minix, he inherited 80% of the minix community because he took patches and Tanenbaum didn't...) There's a famous tanenbaum-torvalds debate preserved for posterity, there is NOT a stallman-torvalds debate because nobody cared what stallman had to say. Nor did he invent freeware, which was the universal norm before the Apple vs Franklin decision in 1983 because you couldn't copyright binaries before Steve Jobs got the appeals court to change the law. Byte and Compute magazines had basic listings in the back of each issue for you to type in, decus and CP/M northwest had software libraries, the commodore 64 came bundled with a disk of Jim Butterfield's software but he didn't WORK for them: he founded the Toronto Pet User's Group (TPUG) and published free software with source code. But Stallman mansplained at everyone else at the top of his lungs nonstop from the moment he showed up, and there are all sorts of topics that can't NOT have an "as opposed to what stallman's saying, the truth is" section today... https://en.wikipedia.org/wiki/Freeware Sigh, watching https://youtu.be/2gOGHdZDmEk and https://youtu.be/WWfsz5R6irs and https://youtu.be/9RO5ZAmzjvI every time the narration talks about Pierre Spray I get Stallman vibes. There's a broadcast version of Dunning-Kruger where you plausibly preach to an audience who doesn't know better, and become The Expert that everybody must get a quote from every time something happens in that area, while the people actually doing the work facepalm at every third word. Rob From aquahobbyist at proton.me Sat Apr 13 12:09:16 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Sat, 13 Apr 2024 19:09:16 +0000 Subject: [Toybox] httpd: How is this supposed to be _used_? Message-ID: <9oWg0ho1dLUSqc43NKwfdxMncRHR_OafMZ1944WnwDiyZKjbLerTJF55Mh508pBMsnnfBYCyX4Q_voeqGdXToRakrIlILNMqi92lPfbFYls=@proton.me> I've been doing networking stuff (Setting up a website), and since I don't want to deal with Apache or the systemd stuff required to do nginx. I decided to give toybox httpd a try. My use case is as simple as simple can be for this type of work, providing some statically generated web pages on localhost so I don't have to deal with "/index.html" linking to my actual root directory when I try to navigate. This practically seems to be what httpd was made for and should be easy to do. The first thing I ran into is that httpd doesn't do that by default, running "toybox httpd dist/" won't actually host those pages on localhost. "Why?": Looking at the source code and typing input into httpd, it wants input from stdin and seemingly outputs to stdout like a normal unix tool (which httpd is usually not). So, it's supposed to get http requests from... somewhere, and in return it outputs the stuff you ask for... somewhere. And you apparently have to know where and/or how to use it in a pipeline for it to become useful. Forgive me, but I'm going to compare this to busybox httpd. A command that needs root privileges (Which makes sense). So when I do "sudo busybox httpd -h dist/", it automatically fires that off in the background and provides my webpages on localhost. The first line of httpd.c describes the command as "Web server", and the command help says "Serve contents of directory as static web pages.", Neither of which provide much insight, or give clues on how you are supposed to use the "HTTP Daemon" with this behavior. I'm assuming there's some file in /proc I need to cat into toybox httpd and redirect the output to somewhere (also likely in /proc) to actually "Serve" these webpages. But I've grepped through the list archives and I can't find discussion on how httpd is actually supposed to be used. Busybox httpd calls: bind(3, {sa_family=AF_INET6, sin6_port=htons(80), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_scope_id=0}, 28) Which isn't particularly insightful and makes this seem like a internal thing. This question probably seems stupid to a networking person, but I've looked far and wide, the busybox source code for httpd (all 2899 lines of it) isn't that insightful. And if there is documentation for the /proc/net networking stuff that handles this I don't know where to find it. How is toybox httpd supposed to be used as to "Serve Web Pages" on a network? - Oliver Webb From aquahobbyist at proton.me Sat Apr 13 23:13:31 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Sun, 14 Apr 2024 06:13:31 +0000 Subject: [Toybox] Microsoft github took down the xz repo. In-Reply-To: References:

Message-ID: To revive a old thread with new technical info I stumbled upon: On Saturday, March 30th, 2024 at 15:58, Rob Landley wrote: > I set up gitea for Jeff on a j-core internal server, and it was fine except it > used a BUNCH of memory and cpu for very vew users. Running cgi on dreamhost's > servers is a bother at the best of times (I don't want to worry about exploits), > and the available memory/CPU there is wind-up toy levels. > > My website is a bunch of static pages rsynced into place, some of which use > xbithack to enable a crude #include syntax, and that's about what the server can > handle. Going through the list of "minimal tools" on https://suckless.org/rocks/, I stumbled upon a git frontend called stagit (https://git.codemadness.org/stagit/file/README.html) which the suckless project uses as it's git frontend. And from looking at it, works purely via static pages and is fairly minimal (2000 LOC in pure C with only non-libc dependency being libgit2. One of it's "cons" is that it's "slow on repo's with 2000+ commits due to diff generation", And then says that it takes 3s to run on a repo with 1500 commits). Have you considered it? The main downside of it is that it's MIT Licensed, which means if you wanted to bundle it in with the main repo there could be be licensing kerfuffles to deal with. But to have a solution, you must have a problem. The 2 main issues I have with the current git management are the fact there doesn't seem to be a way to clone the current repo directly from landley.net (Making Microsoft GitHub the middleman). And the fact I can't browse the source code without github or android code search acting as the middleman (This is a problem I've actually ran into on networks where github is blocked for some utterly insane reason, meaning I have to go to android code search to read through the code occasionally). The first of these seems near impossible to solve with _only_ static webpages, since a git server is not a static thing. I don't know yet tho. The second one seems easier though, copying or maybe symlinking stuff from the source directory with "find" in a pipeline with bash to make a simple, browse-able tree would take probably take a few dozen lines of at most, It could also probably just be an rsync command if you don't want to worry about listing out directory contents. Both of these problems are remediable now, but in a year they might not be (ProtonMail just said "If you don't sign in for a long enough time we will delete all your data" like Google drive is doing, it's not hard to imagine Microsoft GitHub doing a similar thing with accounts they locked out by their 2FA crusade) Rob, Are you interested in future-proofing the codebase from whatever GitHub and AOSP decide to do? This is a situation where I'd normally create a patch and let Rob decide whether to apply it or not. But since I probably shouldn't put the source tree inside the commit/ folder, and this operation can be done with a fancy rsync invocation I'm not sure if writing any code is the correct solution. Thanks, - Oliver Webb From rob at landley.net Sun Apr 14 06:53:33 2024 From: rob at landley.net (Rob Landley) Date: Sun, 14 Apr 2024 08:53:33 -0500 Subject: [Toybox] httpd: How is this supposed to be _used_? In-Reply-To: <9oWg0ho1dLUSqc43NKwfdxMncRHR_OafMZ1944WnwDiyZKjbLerTJF55Mh508pBMsnnfBYCyX4Q_voeqGdXToRakrIlILNMqi92lPfbFYls=@proton.me> References: <9oWg0ho1dLUSqc43NKwfdxMncRHR_OafMZ1944WnwDiyZKjbLerTJF55Mh508pBMsnnfBYCyX4Q_voeqGdXToRakrIlILNMqi92lPfbFYls=@proton.me> Message-ID: <0bf446c4-03a3-8a94-1b6d-851e8ab4c49c@landley.net> On 4/13/24 14:09, Oliver Webb via Toybox wrote: > The first thing I ran into is that httpd doesn't do that by default, > running "toybox httpd dist/" won't actually host those pages > on localhost. It's an inetd client: https://en.wikipedia.org/wiki/Inetd toybox netcat -s 127.0.0.1 -p 88888 -L httpd . I've been meaning to come up with an actual inetd, and possibly lib/*.c plumbing to do standalone servers, but nommu support and rate limiting incoming connections and so on all go in a layer I haven't implemented yet and am not interested in reproducing in multiple commands. Genericizing the plumbing I've already got in netcat, but making it available from individual commands, implies having a standard set of command line utilities that get exposed in commands to specify address to bind to and port to listen on and max simultaneous connections (including max per source IP) and output inactivity timeout.... Possibly some sort of IPSERVER macro flung into the option string, with a corresponding structure in TT and then a function I call? Or maybe just stick with inetd so it's somebody else's problem... I explain this here periodically, by the way: http://lists.landley.net/pipermail/toybox-landley.net/2024-January/030000.html In theory a tcpsvd was contributed to pending long ago, which kind of has the od/hexdump/xxd problem of multiple implementations not sharing code (as I periodically mention here, ala http://lists.landley.net/pipermail/toybox-landley.net/2023-January/029410.html). It's in the todo heap... > "Why?": Looking at the source code and typing > input into httpd, it wants input from stdin and seemingly outputs to > stdout like a normal unix tool (which httpd is usually not). As all inetd clients do, yes: nbd_server.c is another one. Lots of other things (like the tftpd in pending, or dropbear) can work in inetd mode. > Forgive me, but I'm going to compare this to busybox httpd. You do you. Rob From jmakip87 at gmail.com Mon Apr 15 01:53:58 2024 From: jmakip87 at gmail.com (=?UTF-8?B?SmFybm8gTcOka2lww6TDpA==?=) Date: Mon, 15 Apr 2024 11:53:58 +0300 Subject: [Toybox] Microsoft github took down the xz repo. In-Reply-To: References:

Message-ID: On Sun, Apr 14, 2024 at 9:14?AM Oliver Webb via Toybox wrote: > > To revive a old thread with new technical info I stumbled upon: > > On Saturday, March 30th, 2024 at 15:58, Rob Landley wrote: > > > I set up gitea for Jeff on a j-core internal server, and it was fine except it > > used a BUNCH of memory and cpu for very vew users. Running cgi on dreamhost's > > servers is a bother at the best of times (I don't want to worry about exploits), > > and the available memory/CPU there is wind-up toy levels. > > > > My website is a bunch of static pages rsynced into place, some of which use > > xbithack to enable a crude #include syntax, and that's about what the server can > > handle. > > Going through the list of "minimal tools" on https://suckless.org/rocks/, I stumbled > upon a git frontend called stagit (https://git.codemadness.org/stagit/file/README.html) > which the suckless project uses as it's git frontend. And from looking at it, works purely > via static pages and is fairly minimal (2000 LOC in pure C with only non-libc dependency being > libgit2. One of it's "cons" is that it's "slow on repo's with 2000+ commits due to diff > generation", And then says that it takes 3s to run on a repo with 1500 commits). Have you considered it? > > The main downside of it is that it's MIT Licensed, which means if you wanted to bundle it > in with the main repo there could be be licensing kerfuffles to deal with. > > But to have a solution, you must have a problem. The 2 main issues I have with the current git management > are the fact there doesn't seem to be a way to clone the current repo directly from landley.net (Making Microsoft > GitHub the middleman). And the fact I can't browse the source code without github or android code search acting as > the middleman (This is a problem I've actually ran into on networks where github is blocked for some utterly insane > reason, meaning I have to go to android code search to read through the code occasionally). have you tried cloning the repo? seems to work fine to me. $> git clone https://landley.net/toybox/git/ toybox > > The first of these seems near impossible to solve with _only_ static webpages, since a git server is not > a static thing. I don't know yet tho. Git repo with read-only access over http(s) is a static thing. you dont need dedicated git spesific server software in order to give simple pull access. Just host your git folder with any generic http/https server that can host folder of files and knows atleast simple GET request. https://dev.to/chr15m/git-hacks-self-host-a-minimal-git-repo-over-ssh-388h so you can just serve your git folder with any http server (example with bloated python3. httpd should work fine but needs more setup) $>python -m http.server --directory whereever/mybare_repo.git then clone $>git clone http://localhost:8000/ test > The second one seems easier though, copying or maybe symlinking stuff from the source directory with "find" > in a pipeline with bash to make a simple, browse-able tree would take probably take a few dozen lines of > at most, It could also probably just be an rsync command if you don't want to worry about listing out directory > contents. > > Both of these problems are remediable now, but in a year they might not be (ProtonMail just said "If you > don't sign in for a long enough time we will delete all your data" like Google drive is doing, it's not > hard to imagine Microsoft GitHub doing a similar thing with accounts they locked out by their 2FA crusade) > Rob, Are you interested in future-proofing the codebase from whatever GitHub and AOSP decide to do? This is a situation > where I'd normally create a patch and let Rob decide whether to apply it or not. But since I probably shouldn't > put the source tree inside the commit/ folder, and this operation can be done with a fancy rsync invocation > I'm not sure if writing any code is the correct solution. > > Thanks, > > - Oliver Webb > > > _______________________________________________ > Toybox mailing list > Toybox at lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net Jarno From vidar at karlsen.tech Mon Apr 15 02:37:25 2024 From: vidar at karlsen.tech (Vidar Karlsen) Date: Mon, 15 Apr 2024 11:37:25 +0200 Subject: [Toybox] df not working on FreeBSD Message-ID: <2nyidd5cmlsrycdm2wcfjvq2exfho4azjdcvs5wn7vof7xnlpk@pswmnxr7dt5i> Hello, df throws the following error on FreeBSD: root at 140amd64_noopts-usrports:/usr/local/toybox/bin # ./df / df: getmntinfo: Invalid argument A little bit of poking around shows that getmntinfo expects the second argument (the mode) to be one of these, and not 0: sys/sys/mount.h: #define MNT_WAIT 1 /* synchronously wait for I/O to complete */ #define MNT_NOWAIT 2 /* start all I/O, but do not wait for it */ #define MNT_LAZY 3 /* push data not written by filesystem syncer */ #define MNT_SUSPEND 4 /* Suspend file system after sync */ Changing 0 to MNT_NOWAIT in portability.c makes df happy again. -------------- next part -------------- A non-text attachment was scrubbed... Name: toybox_freebsd_df.patch Type: text/x-diff Size: 607 bytes Desc: not available URL: From enh at google.com Mon Apr 15 12:26:40 2024 From: enh at google.com (enh) Date: Mon, 15 Apr 2024 12:26:40 -0700 Subject: [Toybox] today in "shut up, gnu!" In-Reply-To: <60de25d6-0fae-036c-0ab2-8648ccb6578f@landley.net> References: <60de25d6-0fae-036c-0ab2-8648ccb6578f@landley.net> Message-ID: i'd been deliberately _not_ sending you https://www.phoronix.com/news/GNU-Coreutils-9.5-Released for fear of winding you up :-) On Sat, Apr 13, 2024 at 7:34?AM Rob Landley wrote: > > On 4/12/24 13:24, enh via Toybox wrote: > > ~/aosp-main-with-phones$ find external/ -name NOTICE -type l -maxdepth 2 > > find: warning: you have specified the global option -maxdepth after > > the argument -name, but global options are not positional, i.e., > > -maxdepth affects tests specified before it as well as those specified > > after it. Please specify global options before other arguments. > > > > (it does do the right thing, but insists on whining first.) > > I've hit that too, and am big into Not Doing That. Thought I'd blogged about it, > but it could have been irc, or twitter (which I deleted when twitler bought it > but have an archive I should probably post somewhere), or... probably too old > for mastodon? > > There's a reason I get so exasperated about each new gnu/nag I stub my toe on. > It's gone beyond isolated incident into "pattern of looking down on everyone > else and sneering". > > Unix has always been a silent protagonist, without which shell scripts are a > pain to do. If it doesn't work, they'll figure out why. Just behave consistently > (according to SOME kind of understandable logic) and let them keep the pieces. > Sometimes there's a -v flag to activate printfs() stuck into the code, but don't > express opinions when they didn't ASK. (Put them in the man page or --help if > it's that important.) > > This has ALWAYS been the unix way. There are ALWAYS corner cases, and > deterministic behavior is not difficult to debug. The gnu/FSF never got that. > Stallman only decamped to unix under protest, a refugee from the Jupiter > project's collapse orphaning ITS, and he never really understood it. > > RMS did not INVENT the idea of cloning unix with his big announcement in 1983. > Unix was a diverse community starting from the 1974 ACM article, let alone the > Berkeley Software Distribution in 1975. The first full from-scratch Unix clone > (writing their own kernel, compiler, and command line) was Coherent, which > shipped in 1980. Paul Allen copied subdirectories and file descriptors from unix > into DOS 2.0 not long after. Minix started in 1983 and shipped in 1986, and > Linux is 100% a descendant of Minix (developed on minix, its first filesystem > was minix, the development discussion on comp.os.minix, he inherited 80% of the > minix community because he took patches and Tanenbaum didn't...) There's a > famous tanenbaum-torvalds debate preserved for posterity, there is NOT a > stallman-torvalds debate because nobody cared what stallman had to say. > > Nor did he invent freeware, which was the universal norm before the Apple vs > Franklin decision in 1983 because you couldn't copyright binaries before Steve > Jobs got the appeals court to change the law. Byte and Compute magazines had > basic listings in the back of each issue for you to type in, decus and CP/M > northwest had software libraries, the commodore 64 came bundled with a disk of > Jim Butterfield's software but he didn't WORK for them: he founded the Toronto > Pet User's Group (TPUG) and published free software with source code. > > But Stallman mansplained at everyone else at the top of his lungs nonstop from > the moment he showed up, and there are all sorts of topics that can't NOT have > an "as opposed to what stallman's saying, the truth is" section today... > > https://en.wikipedia.org/wiki/Freeware > > Sigh, watching https://youtu.be/2gOGHdZDmEk and https://youtu.be/WWfsz5R6irs and > https://youtu.be/9RO5ZAmzjvI every time the narration talks about Pierre Spray I > get Stallman vibes. There's a broadcast version of Dunning-Kruger where you > plausibly preach to an audience who doesn't know better, and become The Expert > that everybody must get a quote from every time something happens in that area, > while the people actually doing the work facepalm at every third word. > > Rob From rob at landley.net Tue Apr 16 04:41:15 2024 From: rob at landley.net (Rob Landley) Date: Tue, 16 Apr 2024 06:41:15 -0500 Subject: [Toybox] df not working on FreeBSD In-Reply-To: <2nyidd5cmlsrycdm2wcfjvq2exfho4azjdcvs5wn7vof7xnlpk@pswmnxr7dt5i> References: <2nyidd5cmlsrycdm2wcfjvq2exfho4azjdcvs5wn7vof7xnlpk@pswmnxr7dt5i> Message-ID: <2888f502-f916-118d-4000-dbc8c40379da@landley.net> On 4/15/24 04:37, Vidar Karlsen via Toybox wrote: > Hello, > > df throws the following error on FreeBSD: > > root at 140amd64_noopts-usrports:/usr/local/toybox/bin # ./df / > df: getmntinfo: Invalid argument > > A little bit of poking around shows that getmntinfo expects the second > argument (the mode) to be one of these, and not 0: Presumably it worked at one point, but I didn't write that bit... > sys/sys/mount.h: > #define MNT_WAIT 1 /* synchronously wait for I/O to complete */ > #define MNT_NOWAIT 2 /* start all I/O, but do not wait for it */ > #define MNT_LAZY 3 /* push data not written by filesystem syncer */ > #define MNT_SUSPEND 4 /* Suspend file system after sync */ > > Changing 0 to MNT_NOWAIT in portability.c makes df happy again. And doesn't break macos, so I'm not adding the #ifdef in your patch. (I don't have an openbsd test environment lying around, but https://man.openbsd.org/getmntinfo.3 links to https://man.openbsd.org/getfsstat.2 which says the options are MNT_WAIT and MNT_NOWAIT so presumably they're happy too. Commit 7d9ee89d3cf8. Rob From rob at landley.net Tue Apr 16 06:02:27 2024 From: rob at landley.net (Rob Landley) Date: Tue, 16 Apr 2024 08:02:27 -0500 Subject: [Toybox] Microsoft github took down the xz repo. In-Reply-To: References:

Message-ID: On 4/15/24 03:53, Jarno M?kip?? wrote: > On Sun, Apr 14, 2024 at 9:14?AM Oliver Webb via Toybox > wrote: >> >> To revive a old thread with new technical info I stumbled upon: >> >> On Saturday, March 30th, 2024 at 15:58, Rob Landley wrote: >> >> > I set up gitea for Jeff on a j-core internal server, and it was fine except it >> > used a BUNCH of memory and cpu for very vew users. Running cgi on dreamhost's >> > servers is a bother at the best of times (I don't want to worry about exploits), >> > and the available memory/CPU there is wind-up toy levels. >> > >> > My website is a bunch of static pages rsynced into place, some of which use >> > xbithack to enable a crude #include syntax, and that's about what the server can >> > handle. >> >> Going through the list of "minimal tools" on https://suckless.org/rocks/, Not really a fan of that site. I did a roadmap section on them long ago (https://landley.net/toybox/roadmap.html#sbase), but I'm trying to implement mostly compatible versions of things that already exist, and they're trying to invent new things that didn't previously exist because https://xkcd.com/927/ which I mostly consider fragmentation rather than helping, and I try not to encourage them. >> I stumbled >> upon a git frontend called stagit (https://git.codemadness.org/stagit/file/README.html) >> which the suckless project uses as it's git frontend. When microsoft bought github I mirrored my repo on my website so you could pull it from there, but doing that doesn't have any web interface so I did a quick and dirty bash script to upload the "git format-patch" of each commit, with symlinks from the 12 character hash to the full hash (because doing _each_ one was an insanely slow exercise in inode exhaustion). You're once again telling me what I did was not good enough for you, and that I am wrong, and must change to suit you. >> But to have a solution, you must have a problem. The 2 main issues I have with the current git management >> are the fact I'm very tired. >> there doesn't seem to be a way to clone the current repo directly from landley.net (Making Microsoft >> GitHub the middleman). $ git annotate www/header.html | grep -w git fb47b0120 (Rob Landley 2021-09-12 14:33:36 -0500 30)

local

$ git show fb47b0120 commit fb47b0120f7aa73c0821a8c55e15540d83baed01 Author: Rob Landley Date: Sun Sep 12 14:33:36 2021 -0500 Add a local git mirror (todo item since github was acquired)... diff --git a/www/git/index.html b/www/git/index.html new file mode 100644 index 00000000..bade8d1b --- /dev/null +++ b/www/git/index.html @@ -0,0 +1 @@ +Not browseable: git clone https://landley.net/toybox/git $ git log scripts/git-static-index.sh commit 990e0e7a40e4509c7987a190febe5d867f412af6 Author: Rob Landley Date: Sat Dec 24 06:34:11 2022 -0600 Script to put something browseable in https://landley.net/toybox/git https://landley.net/notes-2022.html#22-12-2022 >> And the fact I can't browse the source code without github or android code search acting as >> the middleman I do not have source tree snapshots up. Kinda hard to do in a static manner without uploading rather a LOT of files (and even if you upload each version of "git log" for each file and create an index file for each commit with the ls -lR of the whole tree linking to the relevant version, the URLs to the files are ugly. I can do it, but don't really want to? Linking to individual lines of the file while also having the raw text kinda implies uploading two versions and I just dowanna. Oh, and dreamhost's server config doesn't have sane file associations for all the types so if I put up a .c file it wants to DOWNLOAD it instead of displaying it as text and trying to .htaccess that more of a pain than I'm up for, so I would wind up having blah.c.txt and blah.c.html files and that's just ugly...) Plus, syntax highlighting: you'd THINK there would be some nice linux syntax highlighting packages out there but not counting "use vi" (which doesn't work for me anyway, :syntax = "E319: Sorry, the command is not available in this version")... Searching around I found https://github.com/alecthomas/chroma which is very proud that it's written in "pure go"... except it's a wrapper for a python library, and python's runtime is written in C, so DEFINE PURE... Digging into the aforementioned python (don't get me started) library, the "python-pigmentize" package installs the man page for a command "pygmentize", and the bash completion for the command pygmentize, but does not install the actual command in the $PATH (or anywhere, according to dpkg-query -L python-pygments). That's the point at which I gave up and decided to give my talk using the github page to highlight the code, which txlf projected onto a screen with the room lights on and everything was so washed out you couldn't see any colors anyway. *shrug* Yes, I've thought about it. It's on the todo list. No, I don't see how your static whatsis is going to suck significatly less with this server config and what it WILL do is demand I install lots of prerequisite packages on my development laptop to generate the stuff it rsyncs, and then probably not minimize the rsync change each time but instead want to push lots of irrelevant regenerated changes through phone tethering. You know what half the rsync slowness is? Dreamhost's server at the far end hasn't got all the files cache hot so it has to fault them back in to compare them, and its storage is ok about streaming data but TERRIBLE at seeking. They're cheap, don't meter bandwidth, and I haven't had to migrate in forever... >> The first of these seems near impossible to solve with _only_ static webpages, since a git server is not >> a static thing. I don't know yet tho. > > Git repo with read-only access over http(s) is a static thing. It's been built into git since at least 2013: https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server >> The second one seems easier though, copying or maybe symlinking stuff from the source directory with "find" >> in a pipeline with bash to make a simple, browse-able tree would take probably take a few dozen lines of >> at most, It could also probably just be an rsync command if you don't want to worry about listing out directory >> contents. >> >> Both of these problems are remediable now, but in a year they might not be (ProtonMail just said "If you >> don't sign in for a long enough time we will delete all your data" like Google drive is doing, it's not >> hard to imagine Microsoft GitHub doing a similar thing with accounts they locked out by their 2FA crusade) Yes, that's why I've been publishing my repo through my own website for years. The subtler issue is that sha1sum isn't _that_ hard to induce hash collisions in with crypto miner style setups (https://valerieaurora.org/hash.html) let alone full state actor kit, and Microsoft is quite happy to cash checks from not even the five eyes but https://www.latimes.com/business/technology/story/2019-10-09/github-ice-contract-employee-oppose and such, meaning what I pull from the repo and what I pushed INTO the repo... microsoft had custody of the data in between, I don't trust it. So my website has tarballs and a current git repo, in case anybody feels like comparing. And I don't pull from outside sources, I "git am" human readable patches. (And I have multiple local historical backups on really quite small usb sticks and sd cards and "yes, that hard drive from 2004 wrapped in an old washcloth still works with this USB adapter", just so anybody trying something could never quite be SURE. Can't STOP shenanigans, but I can be enough of a messy pain it's probably not worth bothering...) (Yes I'm aware of signing commits, no I'm not convinced it would help. Maybe, but I haven't read through it and spent an hour in a room with a relevant expert explaining how and why it does what. I'd rather not run a fixed pipe through enemy territory in the first place than trust the pipe to be untappable.) >> Rob, Are you interested in future-proofing the codebase from whatever GitHub >> and AOSP decide to do? https://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs Rob From aquahobbyist at proton.me Tue Apr 16 08:54:34 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Tue, 16 Apr 2024 15:54:34 +0000 Subject: [Toybox] Microsoft github took down the xz repo. In-Reply-To: References:

Message-ID: On Tue, Apr 16, 2024 at 07:53, Rob Landley wrote: >>> Going through the list of "minimal tools" on https://suckless.org/rocks/, > > Not really a fan of that site. I did a roadmap section on them long ago > (https://landley.net/toybox/roadmap.html#sbase), but I'm trying to implement > mostly compatible versions of things that already exist, and they're trying to > invent new things that didn't previously exist because https://xkcd.com/927/ > which I mostly consider fragmentation rather than helping, and I try not to > encourage them. sbase is dead, suckless spends most of their time Implementing X applications and other useful tools. I don?t like them due to their community being very insular, but that?s another problem. Funnily enough, sbase?s readme mentions toybox in ?List of commands we implement?. But I don?t think pulls in toybox code. > You're once again telling me what I did was not good enough for you, and that I am wrong, and must change to suit you Um? yes? That is a very dramatic way to describe the development process of every single piece of software. Isn?t any patch or feature request ever submitted ?this is ?not good enough? to fit my use case. Can we change it so it does?? Your project is really cool; that is why I am here. Compacting over 200 command line tools into under 500k of executable space is a amazing feat. That being said, does that make it perfect? If it was perfect, what reason would I need to be here? Lashing out at me for being abrasive (a model I largely picked up from you and how you interact with projects like Linux-kernel, by the way) is one thing. Lashing out at me Because ?you are admitting that my work isn?t absolutely flawless and trying to get work done to remedy it? is? >>> But to have a solution, you must have a problem. The 2 main issues I have with the current git management >>> are the fact > > I'm very tired. There is nothing stopping you from taking a break. I submit most of my emails to you with the assumption that you?ll get it to eventually, This being one of them. > I do not have source tree snapshots up. Kinda hard to do in a static manner > without uploading rather a LOT of files The full tree only contains a few hundred files, the table of commits has 11000 I think counting the symlinks > https://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs I?ve personally never seen ?Don?t do research and post the products of it showing what you know which helps understand why I think something is a good solution because someone else has already done that and Thought of absolutely everything 100% guaranteed? A productive development model, but you?ve probably Already thought of it, so I shouldn?t do any research on it? - Oliver Webb P.S. I personally don?t mind and can deal with the model of ?Ruthless Pragmatism?. But when the complainants are ?you are saying my code isn?t perfect and suggesting changes? and ?you are doing research I already did years ago (sorry for not magically knowing that or even (*dramatic gasp*) peer reviewing it) and mentioning it to form a coherent model to base your suggestions on.?, I fail to see what ?pragmatism? has to do with any of it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aquahobbyist at proton.me Thu Apr 18 21:37:59 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Fri, 19 Apr 2024 04:37:59 +0000 Subject: [Toybox] [PATCH] "What's autoconf whining about now?": Grep apparently In-Reply-To: References: Message-ID: (Solving issue 461) The sed autoconf problem is also in grep, where it wants exclusively GNU grep to the point where you don't have "GNU" in your version string autoconf will whine. The problem and solution are identical to sed's, C-c C-v from the sed code with a few changes Patch is attached - Oliver Webb aquahobbyist at proton.me -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Die-Autotools-Die-Grep-edition.patch Type: text/x-patch Size: 1943 bytes Desc: not available URL: From aquahobbyist at proton.me Fri Apr 19 23:04:10 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Sat, 20 Apr 2024 06:04:10 +0000 Subject: [Toybox] [mkroot] mkroot package to build lua Message-ID: (Posting this to the list because discussion on the list is preferred over GitHub) Since there is discussion about building a ruby interpreter under mkroot. I decided to take a shot at building a lua interpreter under mkroot. This is as easy as easy can be. Being pure ANSI C, there are a few minor complications though. Lua needs ar to build (a previous unneeded dependency), configuration system stuff if I had to guess. And the default CC is "gcc --std=gnu99" which.... Lua is fairly small (30K LOC that compiles to ~300K statically linked with musl), simplistic, and software that aligns with some of the design principles (Having a few simple base concepts and extending them with syntax sugar to elegantly provide multi-paradigm programming instead of staking layers of "MOAR FEATURES!!!" on until the spec looks like Perl's or C++'s) but is probably out of scope for toybox if I had to guess (Although I was sure about that for the compiler before I bothered to ask). mkroot package is attached, not as a patch because I'm not really sure if this is something that would want to be added. It fit's enough that I felt like I should submit it, but then again linux already has a language in the form of the shell (And awk (and m4 and make counting the toolchain) (And bc technically (And sed if you wanna get _really_ technical))). - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: lua Type: application/octet-stream Size: 410 bytes Desc: not available URL: From vidar at karlsen.tech Sat Apr 20 01:42:24 2024 From: vidar at karlsen.tech (Vidar Karlsen) Date: Sat, 20 Apr 2024 10:42:24 +0200 Subject: [Toybox] shuf works on FreeBSD Message-ID: toys/other/shuf.c builds and runs on FreeBSD and can be enabled in freebsd_miniconfig with CONFIG_SHUF=y. I can't think of a use case for it, but I'm sure there are some. From rob at landley.net Sat Apr 20 09:18:31 2024 From: rob at landley.net (Rob Landley) Date: Sat, 20 Apr 2024 11:18:31 -0500 Subject: [Toybox] shuf works on FreeBSD In-Reply-To: References: Message-ID: <94f12426-c7f9-38a5-f9f6-28161f37e328@landley.net> On 4/20/24 03:42, Vidar Karlsen via Toybox wrote: > toys/other/shuf.c builds and runs on FreeBSD and can be enabled in > freebsd_miniconfig with CONFIG_SHUF=y. > > I can't think of a use case for it, but I'm sure there are some. I thought it was enabled in commit 93c8ea40a back in November? Rob From vidar at karlsen.tech Sat Apr 20 13:24:04 2024 From: vidar at karlsen.tech (Vidar Karlsen) Date: Sat, 20 Apr 2024 22:24:04 +0200 Subject: [Toybox] shuf works on FreeBSD In-Reply-To: <94f12426-c7f9-38a5-f9f6-28161f37e328@landley.net> References: <94f12426-c7f9-38a5-f9f6-28161f37e328@landley.net> Message-ID: On Sat, Apr 20, 2024 at 11:18:31AM -0500, Rob Landley wrote: > On 4/20/24 03:42, Vidar Karlsen via Toybox wrote: > > toys/other/shuf.c builds and runs on FreeBSD and can be enabled in > > freebsd_miniconfig with CONFIG_SHUF=y. > > > > I can't think of a use case for it, but I'm sure there are some. > > I thought it was enabled in commit 93c8ea40a back in November? Ah yes, you are absolutely right. I apologize, I should have checked instead of assuming based on an older release. From aquahobbyist at proton.me Sat Apr 20 19:37:44 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Sun, 21 Apr 2024 02:37:44 +0000 Subject: [Toybox] [PATCH] xxd: -d Decimal Lables flag, Don't cap at one file Message-ID: Looking at xxd, I noticed that the -b[inary] flag wasn't there, Having some facility to print binary is nice, but since printf doesn't have anything in built for it implementing it isn't hard, but it looks _ugly_. Which is why I decided not to do that in this patch. xxd also runs on average about 5 times slower than vim xxd, this is because of read reading 16 bytes at a time, also not hard to fix, but very hard to fix cleanly. xxd has a -d flag to do decimal address lables that I added in this patch. Toybox xxd intentionally caps itself at 1 file per invocation, "Why?": Vim xxd is a bloated pile of garbage with things like EBCDIC support. They added a "improvement" where if you gave 2 files to it, it would rewrite the contents of the second with the output of the first because it was made for operating systems where file redirection wasn't a built in thing. As someone who's lost data because of this, I'm glad there isn't support for this in toybox xxd. But even though we do loopfiles() over the arguments, There isn't any actual way to take advantage of that code since we cap it at one file. Removing the cap doesn't break anything that wouldn't already be broken, so I removed the ">1" in the option string in this patch. - Oliver Webb P.S. As someone who once did a cleanup pass on a vim xxd fork a while back, a reason to not do colorized output is that you are outputting ANSI codes for _every byte, twice_. And unless you have code to optimize that down, your files can take 3/4 times longer to print out via colorized xxd since every line goes from 68 bytes to 420: Colored xxd: 0001d590: 306d 201b 5b31 3b33 376d 3030 1b5b 306d 0m .[1;37m00.[0m 0001d5a0: 1b5b 313b 3337 6d30 301b 5b30 6d20 1b5b .[1;37m00.[0m .[ 0001d5b0: 313b 3337 6d30 301b 5b30 6d1b 5b31 3b33 1;37m00.[0m.[1;3 Normal xxd: 000159a0: 3030 2030 3030 3020 3030 3030 2030 3030 00 0000 0000 000 000159b0: 3020 3030 3030 2030 3030 3020 3030 3030 0 0000 0000 0000 000159c0: 2030 3030 3020 202e 2e2e 2e2e 2e2e 2e2e 0000 ......... -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-xxd-d-Decimal-Address-Label-Don-t-cap-at-one-file-Wr.patch Type: text/x-patch Size: 1696 bytes Desc: not available URL: From aquahobbyist at proton.me Sun Apr 21 09:01:36 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Sun, 21 Apr 2024 16:01:36 +0000 Subject: [Toybox] [PATCH] test.c: [ 10 -eq 010 ] but [[ 10 -ne 010 ]] Message-ID: <58IhCVFad_U2ZXX85KivyYK8snjp-RQ4aZuvC9orF8KlzWF3moZ9qNOfcD_XSaPLUENl6RE_CIcyQCbyiWybZpDASC-IWh39f_QKKxgcr04=@proton.me> [Issue 498](https://github.com/landley/toybox/issues/498) Apparently a "Security Issue" when dealing with 0 padded numbers like strftime %m. (Which only matters on some BSD systems where toybox test is being used but toybox date is not). I'm not entirely convinced this is a good idea since this removes the ability to do [ 100M -lt 10G ], A cool extension toybox provides. "And for what?": The ability to interoperate with the OpenBSD (The only utility set that I found that we care about which doesn't have it) utility set when dealing with 0 padded time numbers apparently. but if you do care about this fairly minor edge case enough to remove cool functionality for it. The patch is attached for you. - Oliver Webb P.S. Have you thought about making "[[" a MAYFORK instead of a NOFORK like busybox does. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-test.c-Only-use-atolx-if-calling-under-so-that-10-eq.patch Type: text/x-patch Size: 1057 bytes Desc: not available URL: From aquahobbyist at proton.me Sun Apr 21 13:25:27 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Sun, 21 Apr 2024 20:25:27 +0000 Subject: [Toybox] [PATCH] test.c: [ 10 -eq 010 ] but [[ 10 -ne 010 ]] In-Reply-To: <58IhCVFad_U2ZXX85KivyYK8snjp-RQ4aZuvC9orF8KlzWF3moZ9qNOfcD_XSaPLUENl6RE_CIcyQCbyiWybZpDASC-IWh39f_QKKxgcr04=@proton.me> References: <58IhCVFad_U2ZXX85KivyYK8snjp-RQ4aZuvC9orF8KlzWF3moZ9qNOfcD_XSaPLUENl6RE_CIcyQCbyiWybZpDASC-IWh39f_QKKxgcr04=@proton.me> Message-ID: Another Possible Solution is to remove support for octal in atolx, the use of zero padded numbers is probably a lot less common than any modern use of octal. Patch 2.0 is attached, Nothing breaks in the test suite - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Stop-Confusing-Zero-Padded-Numbers-With-Octal.-Zero-.patch Type: text/x-patch Size: 880 bytes Desc: not available URL: From aquahobbyist at proton.me Sun Apr 21 17:01:00 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 22 Apr 2024 00:01:00 +0000 Subject: [Toybox] [PATCH] unix2dos: OLDTOY -> NEWTOY Message-ID: <7VbOzsgDlnsoRBUXGQg2DrORhslvgW39ItzSnvsvgvLiFjdLvG6zIwiZb3MC7Fp-O3wm96yQjoQdQqAM8XKtWunGYvfileozbBSZpu9GLLw=@proton.me> I don't wanna flood Rob with patches (Especially since he's been mostly off the list lately). But this isn't a very large or complex patch. Attached - Oliver Webb P.S. I sent out this email, but my mailer froze mid-sending and I don't know if it's got though, the list hasn't sent it back to me so I assume not. Resending -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-unix2dos-Turn-into-OLDTOY-change-help-text-to-match.patch Type: text/x-patch Size: 1024 bytes Desc: not available URL: From enh at google.com Mon Apr 22 14:14:23 2024 From: enh at google.com (enh) Date: Mon, 22 Apr 2024 14:14:23 -0700 Subject: [Toybox] [PATCH] xxd: -d Decimal Lables flag, Don't cap at one file In-Reply-To: References: Message-ID: On Sat, Apr 20, 2024 at 7:38?PM Oliver Webb via Toybox wrote: > > Looking at xxd, I noticed that the -b[inary] flag wasn't there, > Having some facility to print binary is nice, but since printf > doesn't have anything in built for it implementing it isn't hard, > but it looks _ugly_. Which is why I decided not to do that in this > patch. > > xxd also runs on average about 5 times slower than vim xxd, this is > because of read reading 16 bytes at a time, also not hard to fix, but > very hard to fix cleanly. really? a quick glance suggests it reads blocks of sizeof(toybuf)? (or "whatever stdio is using for its buffer" in the -r case.) > xxd has a -d flag to do decimal address lables that I added in this patch. do you have a _use_ for that? i saw it and ignored it when implementing toybox xxd because i couldn't even imagine a use for decimal addresses... > Toybox xxd intentionally caps itself at 1 file per invocation, "Why?": Vim xxd is > a bloated pile of garbage with things like EBCDIC support. They added a > "improvement" where if you gave 2 files to it, it would rewrite the contents > of the second with the output of the first because it was made for operating > systems where file redirection wasn't a built in thing. As someone who's lost > data because of this, I'm glad there isn't support for this in toybox xxd. > > But even though we do loopfiles() over the arguments, There isn't any actual way > to take advantage of that code since we cap it at one file. Removing the cap doesn't > break anything that wouldn't already be broken, so I removed the ">1" in the option > string in this patch. > > - Oliver Webb > > P.S. As someone who once did a cleanup pass on a vim xxd fork a while back, > a reason to not do colorized output is that you are outputting ANSI codes > for _every byte, twice_. And unless you have code to optimize that down, your > files can take 3/4 times longer to print out via colorized xxd since every > line goes from 68 bytes to 420: > > Colored xxd: > 0001d590: 306d 201b 5b31 3b33 376d 3030 1b5b 306d 0m .[1;37m00.[0m > 0001d5a0: 1b5b 313b 3337 6d30 301b 5b30 6d20 1b5b .[1;37m00.[0m .[ > 0001d5b0: 313b 3337 6d30 301b 5b30 6d1b 5b31 3b33 1;37m00.[0m.[1;3 > Normal xxd: > 000159a0: 3030 2030 3030 3020 3030 3030 2030 3030 00 0000 0000 000 > 000159b0: 3020 3030 3030 2030 3030 3020 3030 3030 0 0000 0000 0000 > 000159c0: 2030 3030 3020 202e 2e2e 2e2e 2e2e 2e2e 0000 ......... > _______________________________________________ > Toybox mailing list > Toybox at lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net From aquahobbyist at proton.me Mon Apr 22 14:23:19 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 22 Apr 2024 21:23:19 +0000 Subject: [Toybox] [PATCH] xxd: -d Decimal Lables flag, Don't cap at one file In-Reply-To: References: Message-ID: > On Sat, Apr 20, 2024 at 7:38?PM Oliver Webb via Toybox > toybox at lists.landley.net wrote: > > xxd also runs on average about 5 times slower than vim xxd, this is > > because of read reading 16 bytes at a time, also not hard to fix, but > > very hard to fix cleanly. > > > really? a quick glance suggests it reads blocks of sizeof(toybuf)? (or > "whatever stdio is using for its buffer" in the -r case.) strace-ing it shows: read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 And if you pass in -c 12 to it: read(0, "\0\0\0\0\0\0\0\0\0\0\0\0", 12) = 12 In practice, it's always what -c is > > xxd has a -d flag to do decimal address lables that I added in this patch. > > do you have a use for that? i saw it and ignored it when > implementing toybox xxd because i couldn't even imagine a use for > decimal addresses... Trying to do math with them in awk or expr or some other program where numbers are always read as base 10: $ head -c 0xf head: invalid number of bytes: ?0xf? I think the ability to read base 16 numbers and prefixes in toybox is a really cool consequence of everything being in one binary. But almost every other utility set doesn't have it because most aren't multi-call binaries. - Oliver Webb aquahobbyist at proton.me From enh at google.com Mon Apr 22 15:17:00 2024 From: enh at google.com (enh) Date: Mon, 22 Apr 2024 15:17:00 -0700 Subject: [Toybox] [PATCH] xxd: buffer input via stdio. Message-ID: --- toys/other/xxd.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-xxd-buffer-input-via-stdio.patch Type: application/octet-stream Size: 1287 bytes Desc: not available URL: From enh at google.com Mon Apr 22 15:17:50 2024 From: enh at google.com (enh) Date: Mon, 22 Apr 2024 15:17:50 -0700 Subject: [Toybox] [PATCH] xxd: -d Decimal Lables flag, Don't cap at one file In-Reply-To: References:

Message-ID: On Mon, Apr 22, 2024 at 2:23?PM Oliver Webb wrote: > > > On Sat, Apr 20, 2024 at 7:38?PM Oliver Webb via Toybox > > toybox at lists.landley.net wrote: > > > > xxd also runs on average about 5 times slower than vim xxd, this is > > > because of read reading 16 bytes at a time, also not hard to fix, but > > > very hard to fix cleanly. > > > > > > really? a quick glance suggests it reads blocks of sizeof(toybuf)? (or > > "whatever stdio is using for its buffer" in the -r case.) > > strace-ing it shows: > > read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 > > And if you pass in -c 12 to it: > > read(0, "\0\0\0\0\0\0\0\0\0\0\0\0", 12) = 12 > > In practice, it's always what -c is ah, yeah, the _include_ path uses the full buffer and -r uses stdio buffering, but "regular" xxd was doing neither. i've sent out the trivial patch to switch to stdio. > > > xxd has a -d flag to do decimal address lables that I added in this patch. > > > > do you have a use for that? i saw it and ignored it when > > implementing toybox xxd because i couldn't even imagine a use for > > decimal addresses... > > Trying to do math with them in awk or expr or some other program where numbers > are always read as base 10: > > $ head -c 0xf > head: invalid number of bytes: ?0xf? > > I think the ability to read base 16 numbers and prefixes in toybox is a really > cool consequence of everything being in one binary. But almost every other utility > set doesn't have it because most aren't multi-call binaries. > > - Oliver Webb aquahobbyist at proton.me > From aquahobbyist at proton.me Mon Apr 22 15:25:21 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 22 Apr 2024 22:25:21 +0000 Subject: [Toybox] [PATCH] xxd: -d Decimal Lables flag, Don't cap at one file In-Reply-To: References:

Message-ID: On Monday, April 22nd, 2024 at 17:17, enh via Toybox wrote: > ah, yeah, the include path uses the full buffer and -r uses stdio > buffering, but "regular" xxd was doing neither. i've sent out the > trivial patch to switch to stdio. Thanks, on my machine it improves the speed by about 10Mb/s (~15Mb/s -> ~25Mb/s). - Oliver Webb aquahobbyist at proton.me From rob at landley.net Mon Apr 22 16:53:46 2024 From: rob at landley.net (Rob Landley) Date: Mon, 22 Apr 2024 18:53:46 -0500 Subject: [Toybox] [PATCH] xxd: buffer input via stdio. In-Reply-To: References: Message-ID: On 4/22/24 17:17, enh via Toybox wrote: > --- > toys/other/xxd.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) What's the issue this fixes? It's not: for i in $(seq 1 100); do echo $i; sleep 1; done | ./xxd Because that won't produce output for a couple minutes... Rob From rob at landley.net Mon Apr 22 16:56:12 2024 From: rob at landley.net (Rob Landley) Date: Mon, 22 Apr 2024 18:56:12 -0500 Subject: [Toybox] [PATCH] xxd: -d Decimal Lables flag, Don't cap at one file In-Reply-To: References:

Message-ID: <39385806-488c-517d-b0eb-89fbeb259695@landley.net> On 4/22/24 17:17, enh via Toybox wrote: > ah, yeah, the _include_ path uses the full buffer and -r uses stdio > buffering, but "regular" xxd was doing neither. i've sent out the > trivial patch to switch to stdio. Ah, performance tweak. *shrug* Applied... Rob From aquahobbyist at proton.me Mon Apr 22 16:46:59 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Mon, 22 Apr 2024 23:46:59 +0000 Subject: [Toybox] [PATCH] xxd: buffer input via stdio. In-Reply-To: References:

Message-ID: On Monday, April 22nd, 2024 at 18:45, Rob Landley wrote: > On 4/22/24 17:17, enh via Toybox wrote: > > > --- > > toys/other/xxd.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > What's the issue this fixes? It's not: > > for i in $(seq 1 100); do echo $i; sleep 1; done | ./xxd > > Because that won't produce output for a couple minutes... Look in the other xxd thread, this speeds up the command by about 10Mb/s Because it was reading only 16 bytes at a time, and this makes it read 4096 - Oliver Webb From aquahobbyist at proton.me Tue Apr 23 08:01:25 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Tue, 23 Apr 2024 15:01:25 +0000 Subject: [Toybox] Poke about various minor patches Message-ID: Like I've said before, I'm trying not to flood Rob with patches. And poking about the larger todo items every week wouldn't be helpful to anybody. So here's some of the smaller patches that are >1 week old: UTF-8 Handling Patchs: http://lists.landley.net/pipermail/toybox-landley.net/2024-April/030285.html -- Comment Change in utf8towc() http://lists.landley.net/pipermail/toybox-landley.net/2024-April/030290.html -- Swap out old UTF8 conversion function with wctoutf8() A note on this: wctoutf8 has a bug where if you give MAX_INT it writes one 0xff byte, actual invalid UTF-8. I've touched lib.c enough in these patches that I don't wanna create merge conflicts by submitting yet another lib.c patch (http://lists.landley.net/pipermail/toybox-landley.net/2024-April/030293.html) Config system: http://lists.landley.net/pipermail/toybox-landley.net/2024-April/030289.html -- Add config symbols so "make ipsubcmd" works http://lists.landley.net/pipermail/toybox-landley.net/2024-April/030291.html -- Fix some single command Builds (The "make ipsubcmd" problem) I also submitted another bc.c cleanup patch that removes the -w and -s options, and shrinks the codebase by about 400 lines I think. I can't dig it up on the list archive, so it's attached. - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-bc-Get-rid-of-s-and-w-and-the-code-for-it-unneeded-p.patch Type: text/x-patch Size: 42420 bytes Desc: not available URL: From rob at landley.net Wed Apr 24 11:10:48 2024 From: rob at landley.net (Rob Landley) Date: Wed, 24 Apr 2024 13:10:48 -0500 Subject: [Toybox] DreamHost Security Alert In-Reply-To: <4VPlRT4cwBzyZ5@yakko.sd.dreamhost.com> References: <4VPlRT4cwBzyZ5@yakko.sd.dreamhost.com> Message-ID: <09bb163b-833c-d52f-fc92-7e4f3d1b4ccb@landley.net> Alas, my website's likely to be down for a bit while I explain to them that "the compiler that got used to build an exploit" and "the exploit" can share strings because gnu is incompetent and leaks the path where things got built into the resulting binaries, but that does not mean that the compiler the strings came from in the first place is actually infected. I mean, here's an article from 2018: https://www.bleepingcomputer.com/news/security/mirai-iot-malware-uses-aboriginal-linux-to-target-multiple-platforms/ Rob (I'd point to old blog entries where I went "huh, my compilers got used to build random russian malware" ten years ago, but my blog was on my site so you wouldn't see it unless I fish it out of archive.org...) -------- Forwarded Message -------- Subject: DreamHost Security Alert - Malware on landley.net Date: Wed, 24 Apr 2024 09:53:09 -0700 (PDT) From: DreamHost Abuse Team To: rob at landley.net Hello Rob Landley, We have received a report of malware at the following location: hXXps://landley.net/aboriginal/downloads/old/binaries/1.2.6/cross-compiler-armv7l.tar.bz2 This means that your site has likely been compromised. We have taken the site offline by renaming its directory (appended _DISABLED_BY_DREAMHOST). Please do not re-enable it until you can address the problem. In general, the three most common entry points for a compromised website are: 1. Vulnerable, typically out-of-date software (such as blogs, forums, CMS, associated themes and plugins, etc.) 2. A cracked/brute-forced admin login for a web application like WordPress, Joomla, Drupal etc. 3. A compromised FTP/SFTP/SSH user password. 1. All software you have installed under your domain should always be kept up-to-date with the most recent version available from the vendors' website, as these often contain security patches for known issues. Older versions of well-known and popular web software (including Wordpress, Drupal, Joomla, etc.) are known to have vulnerabilities that can allow injection and execution of arbitrary code. 2. If you utilize a web application with a script-based administrative backend (like WordPress, Joomla, or Drupal), make sure that you're not using a generic username like "admin" or "webmaster" for the user with administrative privileges. Hackers will slowly brute-force common usernames in order to get access to a script's backend and whatever tools exist there that allow file uploads, alterations, or execution of code. 3. FTP/SFTP/SSH passwords can be compromised and used to modify files. The most important part of securing your account in this case is to change your FTP user's password via the (USERS > MANAGE USERS) -> "Edit" area of the control panel. Passwords should not contain dictionary words and should be a string of at least 8 mixed-case alpha characters, numbers, and symbols. It is also recommended to always use Secure FTP (SFTP) or SSH rather than regular FTP, which sends passwords over the internet in plaintext. You can disable FTP for your user(s) within the DreamHost panel (USERS > MANAGE USERS) section. At this point, we recommend logging into your DreamHost server and removing the content we listed. (Note: You may first need to reset the permissions). You should also look for any other files/directories you did not upload yourself and update all your website components where applicable. As for determining which entry point is the cause of this incident, for 1 and 2, you can review the Apache logs for suspicious activity and requests to suspicious files. Keep in mind that we typically only keep around 5 days worth of Apache logs. For 3, you can refer to this article to find recent logins to your user: https://help.dreamhost.com/hc/en-us/articles/214915728-Determining-how-your-site-was-hacked For further help on this topic, you can refer to our Knowledge Base: https://help.dreamhost.com/hc/en-us/articles/215604737-Hacked-sites-overview https://help.dreamhost.com/hc/en-us/sections/203242117-Logs Lastly, we have scheduled an automated malware scan and if anything is found, we will send you a separate email with those results. If you need further assistance, please respond directly to this email. Thank you for your cooperation! -DreamHost Abuse Team From rob at landley.net Thu Apr 25 08:32:53 2024 From: rob at landley.net (Rob Landley) Date: Thu, 25 Apr 2024 10:32:53 -0500 Subject: [Toybox] DreamHost Security Alert In-Reply-To: <09bb163b-833c-d52f-fc92-7e4f3d1b4ccb@landley.net> References: <4VPlRT4cwBzyZ5@yakko.sd.dreamhost.com> <09bb163b-833c-d52f-fc92-7e4f3d1b4ccb@landley.net> Message-ID: <1d738380-ce30-b358-8e77-00e6b8213377@landley.net> On 4/24/24 13:10, Rob Landley wrote: > Alas, my website's likely to be down for a bit while I explain to them that "the > compiler that got used to build an exploit" and "the exploit" can share strings > because gnu is incompetent and leaks the path where things got built into the > resulting binaries, but that does not mean that the compiler the strings came > from in the first place is actually infected. And it's back. Human saw the email thread at 9am and took reasonable action. I was a little annoyed it was down all day, but eh: nine fives. Close enough. They're cheap and I don't have to do it. Rob (Before them I had a server with a static IP where I ran all my own servers, which meant I had one DNS server pointing to all the other services, and a number of sites went "but DNS says you need TWO authoritative servers" and I went "I'm not paying for a second static IP and all the records would point to the first static IP so if it goes down what does being able to look up the name of the services that aren't currently THERE accomplish? And that's before DNS required cryptographic signatures, and then "sender permitted from" showed up in email around then and NONE of those checkers would work without 2 DNS servers so I _couldn't_ set it up... So yes I _could_ get one of my orange pi boards sent to one of the raspberry pi hosting sites that give a static ipv4 as part of the hosting package, but... I really don't want to?) From aquahobbyist at proton.me Thu Apr 25 18:48:05 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Fri, 26 Apr 2024 01:48:05 +0000 Subject: [Toybox] [PATCH] readelf: Zero Pad -S section numbers (More scriptable through cut/awk) Message-ID: - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-readelf-Zero-Padd-S-section-numbers-More-scriptable-.patch Type: text/x-patch Size: 958 bytes Desc: not available URL: From aquahobbyist at proton.me Thu Apr 25 19:34:34 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Fri, 26 Apr 2024 02:34:34 +0000 Subject: [Toybox] [PATCH] strings.test: testing -> testcmd Message-ID: Again, not trying to flood Rob with a storm of patches, but this isn't a very nuanced patch that could spark technical discussion imo (I already have strings -s[SEP] and -w(count \r and \n) implemented but I'm waiting to submit those) Attached. - Oliver Webb -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-strings-testing-testcmd.patch Type: text/x-patch Size: 2332 bytes Desc: not available URL: From enh at google.com Fri Apr 26 08:35:23 2024 From: enh at google.com (enh) Date: Fri, 26 Apr 2024 08:35:23 -0700 Subject: [Toybox] [PATCH] readelf: Zero Pad -S section numbers (More scriptable through cut/awk) In-Reply-To: References: Message-ID: but this isn't what anyone else's readelf does... so now anyone scripting has _two_ problems. (or a bug, if they've only tested against toybox.) honestly, if you're scripting, you should switch to llvm-readelf and its less-machine-unreadable alternative output format instead. On Thu, Apr 25, 2024 at 6:48?PM Oliver Webb via Toybox wrote: > > - Oliver Webb > _______________________________________________ > Toybox mailing list > Toybox at lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net From aquahobbyist at proton.me Fri Apr 26 09:18:03 2024 From: aquahobbyist at proton.me (Oliver Webb) Date: Fri, 26 Apr 2024 16:18:03 +0000 Subject: [Toybox] [PATCH] readelf: Zero Pad -S section numbers (More scriptable through cut/awk) In-Reply-To: References: