<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 13, 2021 at 2:49 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/11/21 4:51 PM, Ryan Prichard wrote:<br>
> On Thu, Jun 10, 2021 at 7:05 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> to show the help for ls. And DON'T want "chroot dir ls --help" to show help<br>
> output for chroot. (Or time. Or nice. Or nohup...)<br>
> <br>
> <br>
> Yeah, I think my ideal would be for --help to apply to the last (sub)command<br>
> preceding it. e.g. When it appears after a subcommand name, it would be parsed<br>
> like any other subcommand flag. For "time", flag parsing (for -p and -v) seems<br>
> to stop at the first non-hyphenated argument.<br>
<br>
Which pulls in the argument parsing as a prerequisite for --help support in<br>
commands like dd, expr, test...<br>
<br>
Sigh. It's possible this is an acceptable cost, I'd just really like to avoid it<br>
if I can. It's that whole "project serving two masters" thing again. The<br>
embedded space is weird. Yes you can fit the computing power of a supercomputer<br>
into a wristwatch, at the expense of the watch's battery life being about 3<br>
hours of actual usage and 12 hours on standby. My mental model has been the<br>
"free toy inside" of a cereal box running two chips off a watch battery. A<br>
modern version of the blinking LED that was in everything in the 90's. [1]<br></blockquote><div><br></div><div>how much of toybox is even buildable (let alone usable!) without Linux or equivalent Unix-y kernel? and afaik you can't run Linux [or equivalent] on any of the Cortex-M series, let alone the 8-bit AVR series or whatever else lives in the sub-Cortex-M realm?</div><div><br></div><div>(maybe things are different in the SH world? TIL^Wlast week i learned [when skeptical of your claim about generating the md5sum.c tables] that SH-4 has a sincos instruction! i don't know of any ARM cores with anything like that. sqrt is about as fancy as they get.)</div><div><br></div><div>and aren't the "free toy inside" crowd even _more_ likely to have one multiplexer binary than others? only folks with disk and memory to throw away will build n separate tools?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Aside: "toybox toybox toybox toybox ls" doesn't seem to work for me:<br>
> <br>
> $ toybox toybox toybox toybox ls --help<br>
> toybox: Unknown command toybox (see "toybox --help")<br>
<br>
Ah, I forgot commit 28c9710edf8b changed that.<br>
<br>
> The reason that --help isn't in the argument parsing plumbing is because then<br>
> commands that don't have arguments wouldn't support --help, not without the<br>
> argument parsing plumbing being unable to drop out when building small binaries.<br>
> <br>
> <br>
> I'm wondering when it's useful to drop the argument parsing plumbing. Is there a<br>
> configuration where CFG_TOYBOX is off, and there is one binary for one command?<br>
<br>
You can make individual command names, or "make change" to do each individual<br>
command in a loop. (Both are listed in "make help".)<br>
<br>
$ make crc32<br>
...<br>
$ nm --size-sort generated/unstripped/crc32<br>
<br>
(Might wanna pipe that to grep -v ' [Bb] ' because bss only exists at runtime,<br>
not in the binary...)<br>
<br>
> Most of the commands take arguments, so I'd think most builds of the toybox<br>
> binary would need some amount of the plumbing.<br>
<br>
Most builds use the multiplexer where the infrastructure is shared between all<br>
the commands, but a lot of small systems cherry pick just the commands they<br>
need. Still, the list of commands that when build standalone don't include<br>
lib/args.c is currently:<br>
<br>
$ grep 'NEWTOY(' toys/*/*.c | grep -v '["]' | grep -v NOHELP | \<br>
grep -v NOFORK | sed 's/.*NEWTOY(\([^,]*\),.*/\1/p' | sort -u | xargs<br>
arch ascii bootchartd bzcat clear count crc32 dd demo_scankey demo_utf8towc<br>
dos2unix expr factor groups hello ip lsmod lsusb more readahead reset rev sync<br>
tac unix2dos w xzcat yes<br>
<br>
Which isn't a huge list. (And half that's in pending or example anyway.)<br>
<br>
I suppose I could make if/else logic for the drop out case still supporting<br>
--help. I wince at this but lemme think about it.<br>
<br>
> > $ ./tar -c README > --help && ./tar -tvf --help<br>
> > <prints "toybox tar" usage with the new --help behavior. previously toybox<br>
> > behaved like GNU tar above.><br>
> <br>
> And now you know why I had it the way it was. It sounds like what you're saying<br>
> is that the toysh "alias" command should be --help aware for builtins.<br>
> <br>
> Ah, I don't think I'd make a special case for alias... not sure how that would work?<br>
<br>
I'm writing a shell as we speak, so... :)<br>
<br>
(Alias is in the near term todo heap but I need to get through job control<br>
first. Job control is a gordian knot I don't get to cut, but there are some<br>
interesting solvents...)<br>
<br>
> So... I don't actually use alias on Android devices. I had suggested it as an<br>
> example that might motivate "ls -l --help" more strongly than convenience and<br>
> expectation. I'm happy enough just editing the --help into the right place on<br>
> the command line.<br>
<br>
I try to have multiple ways:<br>
<br>
toybox --help ls<br>
toybox ls --help<br>
ls --help<br>
help ls<br>
toybox help ls<br>
<br>
Plus the "man" command someday...<br>
<br>
> -Ryan<br>
> <br>
<br>
Rob<br>
<br>
Footnote 1:<br>
<br>
We've run j-core with an ice-40 wired to an spi flash chip and had it export an<br>
spi interface to read from a calculator keyboard/display running off a stack of<br>
3 watch batteries. We haven't YET taped the ice40/spi pair to the front a watch<br>
battery and added an LED and IR sensor as a proof of concept to have a coin cell<br>
run gnuchess all by itself, but that's mostly because you'd have to stack 3 coin<br>
cells to get the voltage the ice40 wants (and adding voltage converter circuitry<br>
would defeat the "two chips scotch taped to a battery bigger than the chips are"<br>
bragging rights thing), so that'll have to wait for an asic SOC version...<br>
<br>
You can get tiny processors for 3 cents<br>
(<a href="https://www.youtube.com/watch?v=VYhAGnsnO7w" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=VYhAGnsnO7w</a>) and a quick search found coin cell<br>
batteries for 36 cents each retail<br>
(<a href="https://www.amazon.com/Panasonic-Cr2032-Lithium-Battery-Ecr2032/dp/B00REWNF2M/ref=asc_df_B00REWNF2M/" rel="noreferrer" target="_blank">https://www.amazon.com/Panasonic-Cr2032-Lithium-Battery-Ecr2032/dp/B00REWNF2M/ref=asc_df_B00REWNF2M/</a>)<br>
presumably cheaper in bulk. (I occasionally look at<br>
htts://<a href="http://landley.net/notes-2017.html#30-09-2017" rel="noreferrer" target="_blank">landley.net/notes-2017.html#30-09-2017</a> and such but "woman invents a<br>
thing, white dude takes credit, his company gets sued for treating employees<br>
terribly and goes bankrupt" is a sadly common story...)<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>