[Toybox] [PATCH] vi: don't exit on ^C or ^D.

[Rob Landley]

On 1/17/20 11:36 AM, enh via Toybox wrote:
> alternatively we could say "we don't actually care about ex, but do
> want to have a 'scriptable vi'" and have a mode where toybox vi takes
> commands that are just vi commands, not ex commands. that's better in
> terms of smaller code, even if it's then a toybox "exclusive".

If ex is basically free and there's no reason _not_ to have it, fine. I just
don't know any demand for it as its own thing.

> either sounds like a good idea to me (with me personally leaning
> towards "just take vi commands until/unless there's a proven need to
> actually be ex compatible, since our only known use case is testing
> vi"), but sounds like a decision for rob.

Accidentally typing the key so that vi claims it isn't in "visual" mode anymore
annoys me, and then I need to undo it. (I think hit escape and i a lot until it
stops?)

That's pretty much my entire interaction with ex. I vaguely recall Al Viro uses
it sometimes instead of sed.

Rob

> /me wonders how vim testing works. anyone know?

I made a "txpect" command for shell testing, might want to look at that. Note
that zero length input is "read a line and discard it"... oh here:

> # Prompt changes for root/normal user
> [ $(id -u) -eq 0 ] && P='# ' || P='$ '
> # run sufficiently isolated shell child process to get predictable results
> SH="env -i PATH=${PATH at Q} PS1='\\$ ' $SH --noediting --noprofile --norc -is"

The @Q syntax is a horrible obscure bash thing that gives you a quoted string
version of the shell variable contents. So the above sets two environment variables:

$P = whatever your default shell prompt should be, given whether you're root or not.

$SH = a shell command line to run to tell the shell NOT to read /etc/profile and
friends, marshall over the host $PATH, use a predictable prompt, and behave in
an interactive manner even though stdin isn't a tty.

Then the tests:

> txpect "prompt and exit" "$SH" "E$P" "Iexit\n" X0

Run "$SH", then read the $P prompt from stderr, then write "exit\n" to stdin,
then expect it to exit with rc 0.

Yes, the prompt is on stderr, not stdout. Because posix says so. I was surprised
too, and had to change it.

And yes, if this has a 2 byte string it will read 2 bytes from the source in
question and match it, and NOT read any other pending input yet.

> txpect "prompt and echo" "$SH" "E$P" "Iecho hello\n" "Ohello"$'\n' "E$P" X0

Run $SH, read the prompt from stderr, send "echo hello\n" to stdin, read
"hello\n" from stdout (note: $'\n' is another bash syntax, says echo -e the
contents of the '' so that turns the \n into ascii 10, which none of these
strings are doing for you), read the prompt, exit 0.

> txpect "redirect err" "$SH" "E$P" "Iecho > /dev/full\n" "E" "E$P" X0

Run $SH, read prompt, write "echo > /dev/fnull\n" to stdin, read a line from
stderr and discard it, read the prompt from stderr again, exit with 0 (note: X
closes the program's stdin so it should exit at that point).

Note "E" by itself reads a full line (until newline) and then there's more data
after that, which we match specifically. O by itself should also do that.

Rob