<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 20, 2024 at 4:08 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/20/24 11:56, Oliver Webb wrote:<br>
> On Wednesday, March 20th, 2024 at 11:39, Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote: <br>
>> More never had the ability to go backwards, less did. Different command.<br>
> <br>
>>From the more help text you get when you press "h":<br>
> <br>
> b or ctrl-B             Skip backwards k screenfuls of text [1]<br>
<br>
$ ls -l /bin/more<br>
-rwxr-xr-x 1 root root 47816 Nov 27  2019 /bin/more<br>
$ dpkg-query -S /bin/more<br>
util-linux: /bin/more<br>
$ cat README | more<br>
<br>
I hit space twice to advance, then hit b and ctrl-b a lot, no effect. At a<br>
guess, that particular gnu/dammit extension which isn't in posix or busybox more<br>
only works on a seekable file.<br></blockquote><div><br></div><div>indeed. "works for me" with real `more foo` but not with `cat foo | more`.</div><div><br></div><div>(and macOS _literally_ uses less for more, though i was wrong this morning when i thought [but didn't strictly say] that ubuntu does; ubuntu's still the same as debian.)</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">
I personally don't want to complicate more because less exists.<br>
<br>
>> > Looking at the other keybindings GNU more provides which I can implement, There's "=" (prints current<br>
>> > line number) ":f" (print filename and line), as well as being able to use the down arrow to go down<br>
>> > (with the added side effect of any escape key doing so too, not the end of the world, especially<br>
>> > since we can't scroll up) That are Implemented them in the attached patch.<br>
>> <br>
>> Again, more and less are not the same command.<br>
> <br>
> No, all of that is more behavior that you can use in more. Try it.<br>
<br>
I just did, above.<br>
<br>
One easy way to distinguish between less and more is that ctrl-c exits more, but<br>
ctrl-c only kills the command producing less's output while leaving less<br>
displaying the scrollback buffer. You need to hit 'q' to get out of less (unless<br>
you've hit something like forward slash where q just appends to the string and<br>
esc doesn't exit that either, but ctrl-c will exit... back to the less prompt),<br>
meaning newbies can get STUCK in less not knowing how to exit it, the way you<br>
can't in "more".<br>
<br>
Oh, here's another difference:<br>
<br>
$ { echo -e '\e[42mcolor\e[0m text'; while true; do echo hello; done; } | more<br>
shows the color change<br>
$ { echo -e '\e[42mcolor\e[0m text'; while true; do echo hello; done; } | less<br>
shows the escape sequences<br>
<br>
That's why I'm still pondering if they can/should usefully share code.<br>
<br>
>> > There is also a testing problem. vi.c doesn't do TEST_HOST because it needs a -s option<br>
>> > to pass in scripts to test with.<br>
>> <br>
>> Which is an issue I need to figure out how to address. What does a test that<br>
>> only toybox passes actually prove? (That it hasn't changed since we last<br>
>> looked at it?)<br>
> <br>
> There is vi -c which preforms a ex command which we could implement<br>
<br>
I leave vi to the people who are maintaining that vi. I got out of way for that<br>
command.<br>
<br>
>> I have been planning one all along, yes. The crunch_str() stuff I did was a<br>
>> first pass at general line handling stuff that could be used by less and by<br>
>> shell line editing and by vi and so on, but people wrote a vi that does not and<br>
>> never will share code with the rest of those so that's off the table<br>
>> permanently.<br>
> <br>
> My experience is in vi.c which is why I mentioned using code from it. I haven't read<br>
> through top or hexedit<br>
<br>
I haven't read through the vi.c in pending.<br>
<br>
>> > But I have to ask the question "If it's so easy, why isn't it in toybox yet?" Is it just because<br>
>> > other TODO items taking up time, or is it because it's harder to implement than it seems.<br>
>> <br>
>> Because I care about edge cases like ansi escapes and utf8 fontmetrics and<br>
>> resizing the screen partway through displaying, because I haven't got test suite<br>
>> infrastructure that can emulate the other half of a PTY yet without which<br>
>> testing has to be manual, because I wanted multiple things to share<br>
>> infrastructure (including potentially stuff like "fold")...<br>
> <br>
> So it's harder to implement than it seems, thank you.<br>
<br>
Well it's harder to TEST. There's a reason I've been working towards mkroot<br>
based test infrastructure with a known kernel and pty wrappers. Kinda hard to<br>
test "ps" or "top" or "watch" at present either.<br>
<br>
I have PART of that test infrastructure in the txpect plumbing in<br>
scripts/runtest.sh which do expect style input/output scripts, currently just<br>
used for sh tests via a "shxpect" wrapper, but the general idea is explained in<br>
the comment before the shell function in runtest.sh:<br>
<br>
# Simple implementation of "expect" written in shell.<br>
<br>
# txpect NAME COMMAND [I/O/E/X/R[OE]string]...<br>
# Run COMMAND and interact with it:<br>
# I send string to input<br>
# OE read exactly this string from stdout or stderr (bare = read+discard line)<br>
#    note: non-bare does not read \n unless you include it with O$'blah\n'<br>
# R prefix means O or E is regex match (read line, must contain substring)<br>
# X close stdin/stdout/stderr and match return code (blank means nonzero)<br>
<br>
So you can go:<br>
<br>
txpect "test name" "bash --noediting -i" \<br>
  E'$ ' I$'echo hello\n' O$'hello\n' E'$ ' I$'exit 42\n' X42<br>
<br>
Which runs bash with a pile of flags (the shxpect wrapper also calls env -i and<br>
manually sets PATH and PS1, and then adds --noprofile and --norc so it doesn't<br>
override them on its way up), and then:<br>
<br>
1) reads the '$ ' prompt from the child's stderr, dying if it can't (um, 10<br>
second timeout I think?) And yes, interactive shell prompts to go stderr, not<br>
stdout.<br>
<br>
2) Feeds 'echo hello' followed by a newline to the child's stdin, using the<br>
shell's $'blah' escape parsing syntax to convert the \n into low ascii.<br>
<br>
3) reads "hello\n' from the child's stdout.<br>
<br>
4) reads another prompt on stderr.<br>
<br>
5) tells the shell to exit with error code 42.<br>
<br>
6) waits for the child to exit with error code 42.<br>
<br>
Actually making that WORK reliably involved creating FIFOs behind the scenes,<br>
you'd think the shell would be better about circular pipes but so far... Since I<br>
wrote that, bash added a "coproc" command which I probably have to implement at<br>
some point but am NEVER going to personally care about because they built it on<br>
arrays, which is just sad.<br>
<br>
Meanwhile, the people who took vi away and ran with it seem to think testing the<br>
interactive bits are irrelevant, and that "vi" is just "ex" with a GUI. I have<br>
not attempted to argue with them.<br>
<br>
Anyway, what txpect does NOT do is let you specify a screen size or query cursor<br>
position for the child process, the way a command like "screen" does. I need to<br>
set up a pty master process and interact with the child through it somehow,<br>
which is pending design work. I probably have to create a<br>
toys/example/demo_pty.c and command and have the test depend on that being in<br>
the $PATH, because I am NOT having the test suite call a compiler at the design<br>
level. (The test suite is not dependent on the build environment, therefore it<br>
cannot compile small C programs as part of a test.)<br>
<br>
In THEORY mkroot/packages/tests should be able to do something like:<br>
<br>
  cp -D scripts/{runtest,portability,test}.sh "$ROOT/test/scripts/"<br>
<br>
And just run the tests with a smallish wrapper script to make directories and<br>
maybe set up environment variables. Installing a native toolchain into the new<br>
filesystem is _not_ a dependency. Which makes the pty wrapping awkward at a<br>
design level...<br>
<br>
Rob<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>