Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001185 [1003.1(2016)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2018-02-02 04:13 2018-02-14 18:22
Reporter dannyniu View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name DannyNiu/NJF
Organization
User Reference
Section more
Page Number http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html [^]
Line Number EXTENDED DESCRIPTION
Interp Status ---
Final Accepted Text
Summary 0001185: Additional 3rd option for getting line size.
Description Since we've had bug 1151 introducing new signals and IO control calls to get and set terminal sizes, we should have a 3rd option for more to get terminal size to display text on screen.
Desired Action In Extended Description, 2nd paragraph:

Change

The number of lines available per screen shall be determined by the -n option, if present, or by examining values in the environment (see the ENVIRONMENT VARIABLES section). If neither method yields a number, an unspecified number of lines shall be used.

to

The number of lines available per screen shall be determined by the -n option, if present, or by examining values in the environment (see the ENVIRONMENT VARIABLES section), or by calling tcgetwinsize. If no method yields a number, an unspecified number of lines shall be used.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0003916)
dannyniu (reporter)
2018-02-02 04:24

Additionally, add a "Signals" section, with:

SIGWINCH: When received, "more" may update the terminal with new output to refresh the screen.
(0003920)
kre (reporter)
2018-02-13 23:54

Which versions of more(1) have a -n option like that?

Or are you suggesting that we should invent something
which does not currently exist?

kre
(0003921)
nick (manager)
2018-02-14 02:29

Solaris's /usr/xpg4/bin/more supports the -n option as described, as does OpenBSD's. There may be others.
(0003922)
shware_systems (reporter)
2018-02-14 04:53
edited on: 2018-02-14 05:20

I think I'm with kre on this, that it looks more invention than valid. The description doesn't make any mention of changing a viewport or terminal window's size. It just relates to how many line's are accessed per screen refresh, to override other reported values, and if someone specifies a value larger than tcgetsize() some display scrolls off the top with each b or f command and a user would need to use a k command to see those extra lines, or a scroll-bar/up arrows on a viewport. That's how I think most would read that, at least, as something all terminals can support.

Relating it to how many lines of piped input get buffered for use with the k command, where b can't be supported, looks like an omission. Its usual usage would be more if you have a 43 line screen you may say -n 40 to keep the line count per screen as multiples of 10 until the last 'page', to ease lines per file counting, similar to the usage caveat for the LINES variable in XBD 8.3. If the mode suddenly went up or down to a 24 or 50 line screen, I think people would still expect it to access the 40 lines at a time.

This is not to say such autosizing couldn't be useful, but I'd expect a separate switch used in conjunction with -n to enable that behavior when the utility starts, as something applicable only to terminal types capable of supporting it such as a GUI viewport. Whether the display gets restored upon exit or not to the size it was when the utility started would also be something to be specified with a switch like this. I'd expect the utility to auto-adjust, maybe, if -n wasn't specified and the utility was using a value larger than the new size could support when a SIGWINCH was received, but not when -n is specified.

(0003923)
kre (reporter)
2018-02-14 10:44

Other versions of more use -n for a different purpose (a flag, with no
accompanying arg) so I doubt it would be a good idea to standardise that.

Further, I also am not sure I see a need, one can always just do

    LINES=36 more ...

if that is the objective for some reason, though personally I am not sure
I see any use for being able to specify more or less than the actual
terminal page size (what LINES, if it is set at all, should be, and
otherwise the tcget... call result)

kre
(0003924)
shware_systems (reporter)
2018-02-14 18:22

No, -n is standard already, with a required argument. Those using it as just a flag are non-conforming. See link above.

One can always buy 6 VGA monitors and stack them vertically if they want 300 lines of desktop, which tcgetwinsize() may report as available lines, yet many terminals say ok, I'll save 150 (-n) but only show you 30 lines (LINES) at a time so I don't have to span screens, even if this may be using 50 lines for some VGA modes (which would be indicated in TERM somehow).

Doing scrolls out of RAM is still quicker than having to read a disk multiple times, if it's only buffering 30 lines, and how some background applications might be using the other 20 lines and 5 monitors is the user's choice. Yes, when you only have 24 line screens there's little point to using fewer, but "screens" supporting over 600 lines are plausible now for under USD10K.

- Issue History
Date Modified Username Field Change
2018-02-02 04:13 dannyniu New Issue
2018-02-02 04:13 dannyniu Name => DannyNiu/NJF
2018-02-02 04:13 dannyniu Section => more
2018-02-02 04:13 dannyniu Page Number => http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html [^]
2018-02-02 04:13 dannyniu Line Number => EXTENDED DESCRIPTION
2018-02-02 04:24 dannyniu Note Added: 0003916
2018-02-13 23:54 kre Note Added: 0003920
2018-02-14 02:29 nick Note Added: 0003921
2018-02-14 04:53 shware_systems Note Added: 0003922
2018-02-14 05:03 shware_systems Note Edited: 0003922
2018-02-14 05:20 shware_systems Note Edited: 0003922
2018-02-14 10:44 kre Note Added: 0003923
2018-02-14 18:22 shware_systems Note Added: 0003924


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker