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