|Anonymous | Login||2018-12-12 11:51 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Page Number||http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html [^]|
|Line Number||EXTENDED DESCRIPTION|
|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.|
In Extended Description, 2nd paragraph:
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.
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.|
Additionally, add a "Signals" section, with:
SIGWINCH: When received, "more" may update the terminal with new output to refresh the screen.
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?
|Solaris's /usr/xpg4/bin/more supports the -n option as described, as does OpenBSD's. There may be others.|
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.
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)
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.
|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|