<div dir="ltr"><div dir="ltr">On Thu, Jun 10, 2021 at 7:05 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/9/21 9:00 PM, Ryan Prichard wrote:<br>
> It seems to have broken --help when invoking toybox explicitly:<br>
<br>
Because you asked it to. There's a reason it wasn't doing it from any position<br>
before.<br>
<br>
> $ ./toybox ls --help<br>
> <shows same output as "./toybox --help" rather than the "toybox ls" usage.><br>
<br>
ls one two three --help: produces help output for ls.<br>
toybox ls banana --help potato: produces help output for toybox.<br>
<br>
You want me to special case toybox to NOT accept --help in any but the first<br>
position? Except you presumably also want:<br>
<br>
toybox toybox toybox toybox ls --help<br>
<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></blockquote><div><br></div><div>Yeah, I think my ideal would be for --help to apply to the last (sub)command preceding it. e.g. When it appears after a subcommand name, it would be parsed like any other subcommand flag. For "time", flag parsing (for -p and -v) seems to stop at the first non-hyphenated argument.</div><div><br></div><div>Aside: "toybox toybox toybox toybox ls" doesn't seem to work for me:<br></div><div><br></div><div>$ toybox toybox toybox toybox ls --help<br>toybox: Unknown command toybox (see "toybox --help")<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You've convinced me to revert the patch I did. It makes things worse. There is a<br>
"help" command, and there's a "man" command in pending I gave up trying to clean<br>
up after I threw away what I'd done three times because somebody else had yet<br>
another patch to it. (It's now behind "dd" in the to-clean-up list.)<br></blockquote><div><br></div><div>Yeah, I agree with reverting the patch.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></blockquote><div><br></div><div>I'm wondering when it's useful to drop the argument parsing plumbing. Is there a configuration where CFG_TOYBOX is off, and there is one binary for one command? Most of the commands take arguments, so I'd think most builds of the toybox binary would need some amount of the plumbing.</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">
> $ ./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></blockquote><div><br></div><div>Ah, I don't think I'd make a special case for alias... not sure how that would work?</div><div><br></div><div>So... I don't actually use alias on Android devices. I had suggested it as an example that might motivate "ls -l --help" more strongly than convenience and expectation. I'm happy enough just editing the --help into the right place on the command line.</div><div> </div><div>-Ryan</div><div><br></div></div></div>