On Fri, Nov 3, 2023 at 7:22 AM Rob Landley <r...@landley.net> wrote: > > On 11/2/23 16:56, enh via Toybox wrote: > > This frees up 'x' for xmodem transfers later. > > Q to quit makes sense, adding xmodem... do you have an xmodem protocol > extension > in mind that doesn't pad the last packet up to 128 bytes?
that is annoying, yes, but since my only purpose is transferring executables, i don't think it matters? (and even in the case where it does, toybox already has a truncate(1).) > What xmodem command > are you going to run at the other end to consume the data and send the > replies, i was going to write one. the xmodem spec sounds like it's only going to be tens of lines. > and how will the terminal program know to run it? i think for unix implementations of xmodem it's more common for the user to do that part? the xmodem spec does talk about having sx send "rx\r" and rx ignoring crap like that at the start, but that seems gross enough to wait until someone actually _needs_ that. > I still lean towards running a child command here. Heck, _vi_ has that (for > some > reason), I know because I keep hitting it accidentally. yeah, like i said earlier when we were talking about the progress indicator --- "call out to sx(1)" is the obvious way to implement xmodem, so replacing my custom "cat-alike with progress indicator" with _actual_ cat(1) wouldn't be unreasonable (even if i'd be a little sad to lose my progress indicator). > Whether we then add a > zmodem command to toybox is a separate question... *z*modem is way more complicated (and still kind of a mess). > > Also, if we're going to have a single line of help, switch to the more > > common format for such prompts > > More common where? All the hits for grep '"[^"]*[[].[]][^"]*"' toys/*/*.c > lib/*.c main.c are false positives finding array access between two strings. I > don't think I've seen toybox use this anywhere else? oh, yeah, since my unzip(1) is c++ and uses Android's libziparchive i only upstreamed the unzip _tests_ to toybox, didn't i? in terms of _toybox_ precedent, well, that's why i had the original multi-line format :-) (toybox telnet uses multiple lines because _busybox_ telnet does.) i can't think of any other interactive prompting in toybox. but (as i just spoilered), unzip is about the only "unix" tool (in the weaker sense of "something most unix users have come across at some point" anyway) that has an interactive prompt (when it needs to overwrite something), and it uses this style. and it's certainly more readable than the "busybox telnet squished onto one line" style, and the fact that the checked-in spacing between options wasn't even correct seemed like a strong indicator to me that "this is not the way to do it" :-) > Then again, grep '"[^"]* .)[^"]*"' toys/*/*.c lib/*.c main.c isn't finding > any > other non-false-positive hits. If you have a strong opinion about this, I can > switch, but I just want to be clear that either way this seems to be > introducing > a new rule into the project, and you want that rule to be [a] command rather > than a) command. well, i'm actually suggesting "[c]ommand" rather than "c) command". but, yes, i think if you prefer "c) command" then we should actually switch to "toybox --help" style where it's _usually_ one per line (and there's a whole _tab_ for clear and consistent spacing) ... until/unless you end up with lots of lots of options, at which point things get a bit ascii-art. (_that_ "toybox --help" style was actually my first thought for toybox telnet too, if i'm honest, but either choice seemed like "innovation" and i fell on the side of "same ui as busybox" being "less innovative". which then naturally led to me doing the same for microcom.) my other other thought (which i also didn't pursue because i liked the telnet precedent of the "Escape character ..." line) was outputting something like toybox microcom Press ctrl-] q to quit. Press ctrl-] ? for help. on startup. (though i'd still probably have had the ctrl-] ? help output be one per line, but perhaps you wouldn't have been as offended by the verbosity if the user had _asked_ for help?) > > (and, if nothing else, fix the previously > > inconsistent spacing between options > > Yup, my bad. :) > > > and make it clear what new options > > should look like). > > I'd rather not apply the patch as is because of the above commit comment > grumbles, but don't object to code change itself. Should I switch the -64 to > &31 > while I'm there? (i still think we should do that properly as you described --- let's have the macro, but have it do the _right_ thing and `^ 0x20` first.) > Rob > > P.S. Oh goddess, I just "grep -ir modem busybox/" and yes busybox has an "rx" > command. But it doesn't have a corresponding sx command, which makes every > little sense? Who sends it files? > > https://unix.stackexchange.com/questions/186706/what-is-the-complementary-command-to-rx-for-xmodem-transfer indeed. that's why i'd add rx _and_ sx, and have microcom know how to run sx. (it would help with being able to at least do some round-trip testing too!) _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net