On Sat, Apr 23, 2016 at 8:41 PM, Rob Landley <[email protected]> wrote: > On 04/23/2016 04:40 PM, enh wrote: >> On Sat, Apr 23, 2016 at 12:39 PM, Rob Landley <[email protected]> wrote: >>> On 04/21/2016 07:42 PM, enh wrote: >>>> And add a test. >>>> --- >>>> toys/pending/more.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> Applied, but I don't see the test? >> >> d'oh. fooled by git commit -a yet again. >> >>> Sigh: I wanted "more" and "less" to share code, but they really don't do >>> the same thing (random example: "ls --color | more" vs "ls --color | less"). >> >> there's "less -r". but i didn't know that until i read the help just now :-) > > And this implementation of more has approximately the same problem that > less -r's man entry documents about keeping track of where it is on the > screen: > > putchar(ch); > if (ch == '\t') col = (col | 0x7) + 1; > else col++; > if (col == cols) putchar(ch = '\n'); > if (ch == '\n') { > > That treats the ansi escapes as normal printing characters for > determining when the screen wraps, in which case this inserts a > gratuitous newline (instead of allowing the screen to wrap itself)... > > The posix more spec says it gets the screen height from -n or an > environment variable and if neither are set it uses an _unspecified_ > number of lines. Actually querying your terminal size is nonstandard > behavior. Lovely. > >> having more(1) be the simplest possible thing probably best matches >> the intentions of anyone who deliberately chooses more(1) over less(1) >> anyway. > > We have two lines of colons instead of one when announcing a new file. I > can't find ANY reference to a line of colons in the posix thing,
i had no idea there was a POSIX more(1). or that it's more like less(1) than any real more(1). (the only obviously annoying thing is that they say ' ' should behave like '\n', rather than keeping the page vs line behavior that both more(1) and less(1) have in real life.) your earlier comments about sharing with less/vi make a lot more sense in the context of the hypothetical POSIX more(1) :-) > the > closest I can find is this bit of the extended description: > >> For all files but the last (including standard input if no file was >> specified, and for the last file as well, if the -e option was not >> specified), when more has written the last line in the file, more >> shall prompt for a user command. This prompt shall contain the name >> of the next file as well as an indication that more has reached >> end-of-file. If the user command is f, <control>-F, <space>, j, >> <newline>, d, <control>-D, or s, more shall display the next file. >> Otherwise, if displaying the last file, more shall exit. Otherwise, >> more shall execute the user command specified. > > Which says nothing about the format... > > Sigh. "Simple." Right... > > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
