[Toybox] [PATCH] microcom: move from e[x]it to [q]uit.

[enh]

On Fri, Nov 3, 2023 at 7:22 AM Rob Landley <rob at 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!)