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@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net