0001053: Add a "size" mode to stty(1) - Austin Group Defect Tracker

Notes
(0003203) shware_systems (reporter) 2016-05-10 22:15	The utility already standardized, via XCurses, to provide that information is tput, not stty. That is the one I feel is missing the 'rows' and 'cols' operands in XCU to report the system default or TERM specific maximum values, whether XCurses' TERMINFO derived or not, since some default value is required. Dynamic resized values are more the province of pathconf() / getconf, I believe. The use of 'size' with stty I see as a LEGACY option, as where implementations prior to the introduction of tput put the reporting functionality rather than provide a separate utility.

(0003204) geoffclare (manager) 2016-05-11 09:11	I have always used "stty -a" for this; I had not come across "stty size" before. A quick check of systems I have access to shows they all output rows and columns in the stty -a output, but Solaris does not support "stty size". As pointed out in Note: 0003203 the information is also available from tput, although it is only required by the XCurses spec, not by XCU. In XCurses the relevant operands are "lines" and "cols" (not "rows" and "cols"). So there would seem to be four choices: 1. do nothing 2. add the "size" operand to stty 3. add a requirement for stty -a to output "rows" and "columns" 4. add the "lines" and "cols" operands to tput in XCU (or some combination of 2, 3 and 4). I would prefer 3 or 4 over 2 because they are more widely implemented. I would prefer 4 over 3 because the output is easier to parse in the shell. So my vote would be to do either 4 or both 3 and 4.

(0003205) shware_systems (reporter) 2016-05-11 10:20	I used size to match the report title; what option letter or other argument matches existing practice best I didn't investigate. For tput 'width' and 'height' might be better, actually, to make them independant of TERMINFO entirely. A -d option for specifying device paths like /dev/tty or /dev/console could be useful also.

(0003206) dickey (reporter) 2016-05-11 10:20	Agreeing with that summary (3 and 4 are existing practice, so standardizing them would be the way to go), the main impediment to parsing stty output is because of some other legacy items which do not use the same syntax. For example, "eucw" and "scrw": speed 38400 baud; 40 rows; 80 columns; eucw 1:1:0:0, scrw 1:1:0:0: intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = ^@ eol2 = ^@; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; reprint = ^R discard = ^O; werase = ^W; lnext = ^V -parenb -parodd cs8 -cstopb -hupcl cread -clocal -parext -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc ixon -ixany -ixoff -imaxbel isig icanon -xcase echo echoe echok -echonl -noflsh -tostop echoctl -echoprt echoke -flusho pending iexten opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3

(0003207) joerg (reporter) 2016-05-11 10:30 edited on: 2016-05-11 11:36	@ Note: 0003204 I would support 3) and 4) as they are implemented already by all platforms I am aware of. Note that there are internationalized and localized versions of stty and for this reason, the strings "rows" and "columns" may be printed in the local language unless LC_ALL=C is used, @ Note: 0003205 What is wrong with stty < /dev/ttya?

(0003208) steffen (reporter) 2016-05-11 11:32 edited on: 2016-05-11 11:37	\| I had not come across "stty size" before Yes, i was afraid you would be looking at the Solaris version. But it seems that, e.g., the HP/UX version does support it, under the topic "Reporting functions", which is a much better name than what i've used above. \| I have always used "stty -a" for this POSIX doesn't specify the exact output format of -a, and in effect the output isn't easily parsable. Your item 3., «add a requirement for stty -a to output "rows" and "columns"» is something good, and existing practice, but can't be used for fetching these values for further use. Your item 4., «add the "lines" and "cols" operands to tput in XCU» is an option i didn't think about, it is especially valuable now that tput(1) is in BASE. The minor mismatch in between "cols" and $COLUMNS is, well, just a minor oddity. Still i would prefer a standardized "size" mode for stty(1), your item 2., because it gives all the necessary information in an easily parsable output, and in a single invocation: ?4[steffen@wales ]$ stty size 42 161 ?0[steffen@wales ]$ tput lines 42 ?0[steffen@wales ]$ tput cols 161 ?0[steffen@wales ]$ tput lines cols 42 Item 1., «do nothing», hopefully not, because $LINES and $COLUMNS is what the world's most famous text-based MUA, and my own little one, now actively maintain in order to be able to enable RFC 1524 etc. subprocesses to easily access the current dimensions of the terminal, because these values are currently not accessable otherwise in a POSIX environment. (For the POSIX standard it is true that even a C program either has to link against an external library, let it be a standardized one, or has to issue a non-standardized ioctl(2) in order to become aware of the current terminal dimensions.This is kind of odd given that the pure POSIX standard has all the necessary functionality to implement an interactively usable program that ensures that users are presented a visually appealing text-based interface; considering the user chosen terminal dimensions seems to be a vivid part of which.I want to remark that the mentioned ioctl(2), TIOCGWINSZ, and its argument structure, struct winsize, also seems to be most widely available.) My proposed update to "Desired Action" would thus be as follows: stty(1): after line 3226, add a new list "Reporting functions" and add an initial item size Print the number of rows and columns of the terminal as two space-separated decimal integers. tput(1): add, on page 3269, after line 109703 lines Print the number of terminal lines in the format specified for [link]$LINES[/]. columns Print the number of terminal columns in the format specified for [link]$COLUMNS[/]. A.8.3, Other Environment Variables: change, on line 118193 ff., This size is typically known to the implementation through the value of TERM, or by more elaborate methods such as extensions to the stty utility or knowledge of how the user is dynamically resizing windows on a bit-mapped display terminal. to This size is typically known to the implementation through the value of TERM, or knowledge of how the user is dynamically resizing windows on a bit-mapped display terminal. The current size can be queried with the stty and tput utilities.

(0003215) EdSchouten (updater) 2016-05-11 20:54	Would it make sense to also standardize the C interface for this? Seems a bit weird to have stty(1) support this, but not standardize its underlying primitive.

(0003216) shware_systems (reporter) 2016-05-11 23:13	Re: 3207 Using the option form does not require an open connection, a pipe does. How the implementation would map a path to terminal data would be unspecified. Re: 3215 For base POSIX, I can see using sysconf() or pathconf(), as suggested. The standard already supports adding a constant like _SC_GETTERMLINES or _PC_GETROWS. Something like tcgetlines() or tcgetrows() in termios.h I'd expect to be related to the termios structure or a file handle.

(0003217) kre (reporter) 2016-05-12 02:23 edited on: 2016-05-12 02:24	First, forget tput as a solution to this, its intent is to extract data from terminfo and hence its output depends upon TERM being set correctly. And I agree, attempting to force parsing stty -a output would be absurd, there's no common format, and attempting to impose one would be (again) attempting to achieve results via legislation, which is not what any standards body should be doing. stty size on the other hand is very widely implemented, with consistent semantics - that is the very thing that it is reasonable to include in the standard (after which the very few systems that don't implement most likely very quickly will.) A standard C interface to obtain the data seems like a good idea, but a different question to be considered elsewhere - after a review to determine whether there is any existing common method that qualifies to be standardised.

(0003218) stephane (reporter) 2016-05-12 06:18	Those cols and rows are also retrieved from attributes of the tty device like the rest of the things that stty deals with, so it makes sense to have it there. In the implementations that I know, the values are generally set by the terminal emulator (via the master side of the pseudo-terminals) as they are the ones that now the truth or getty or the kernel (for virtual consoles) and passed along (dynamically via the SIGWINCH signal also not covered by this spec) by things like telnet or ssh or screen. When that's not passed along, or when getty guesses the wrong size for a terminal, it's often useful for applications to change that size themselves, and then again: stty rows 50 cols 120 seems to be widely supported (maybe even more widely than stty size as Solaris supports it). Now, some terminals can also be queried their size via escape sequences, that's more like what I'd expect tput to do (though in practice the one from ncurses at least seems to query attributes of the tty device instead like stty (which is less intrusive and more reliable even if not always as accurate)). In anycase, "stty size" is clearer of what size we're talking about: the size as stored in the tty device regardless of whether it reflects the actual size of the terminal screen (if any) that is at the end (possibly through a long chain like in the case of ssh over telnet over rlogin) of that tty device.

(0003219) philip-guenther (reporter) 2016-05-12 06:51	--- Begin data point about existing practice --- At least for BSD systems, the TIOCGWINSZ ioctl() is the underlying method of getting this information and the TIOCSWINSZ ioctl() can be used to change it. "stty size" and "stty all" use the former while the stty 'rows' and 'columns' settings use the latter to change what the system reports. At least on OpenBSD, tput supports the lines and columns queries; it's built on the ncurses library which appears to use the ioctl(), but letting the LINES and COLUMNS environment variables override that. --- End data point about existing practice --- POSIX has treated standardization of ioctl() APIs to termio as abhorrent with ioctl() itself only originally standardized for STREAMS use and now completely removed from the standard. Good Riddance. So, providing a standard C API at this point will require some sponsor to step up and back one. --- Begin despondent opinion --- It's been long enough since that happened that I no longer even remember what API was last added per that. AFAICT, the groups that can sponsor additions have lost interest in doing so; far more important/useful APIs that been requested and "just" need sponsoring have been ignored. Does anyone even remember who someone would need to convince in order to get an API added?

(0003220) dickey (reporter) 2016-05-12 08:36 edited on: 2016-05-12 08:47	Re: 3218 None of the systems I've examined have a "size" keyword in the output from "stty -a". Almost all (AIX, HPUX, Solaris, Linux, {Free/Net/Open}BSD) use the keywords "rows" and "columns". I found one exception: QNX using "rows" for comma-separated numbers. None use the keyword "cols" (which is used by tput). tput, by the way, uses short terminfo names on these platforms ("columns" is defined as the long name corresponding to "cols"). Given these differences between input ("stty size") and output ("stty -a"), it seems that the input was added as an afterthought. The main difference between AIX, HPUX and Solaris is that AIX and Solaris show "eucw" and "scrw", and Solaris shows "csdata" (none are mentioned in the manual pages). Again, an afterthought.

(0003221) geoffclare (manager) 2016-05-12 09:50	Re: the comment in Note: 0003217 "there's no common format" for stty -a output, the standard does partially specify the output format - it specifies how speeds and control characters are output. My thinking was that rows and columns could be specified the same way. However, I now see that some implementations output "rows = X; columns = Y;" and some output "rows X; columns Y;" so I'm less in favour of this solution than I was.

(0003222) steffen (reporter) 2016-05-12 10:27	\|Would it make sense to also standardize the C interface for this? Seems a bit weird to have stty(1) support this, but not standardize its underlying primitive. I would very much welcome this, and add the SIGWINCH signal, just like many software projects would. I'm used to the Unix/POSIX interface starting around 1999, but better 2000, always had this ioctl (the alternative being TIOCGSIZE with struct ttysize) around, and can only assume that it must root in some kind of jealous territorial biting that it didn't enter the standard. (Or that it was in an early draft and has been removed due to lack of compromise or the like.) E.g., if i look in my local code arena, via "git grep -q TIOCGWINSZ master && echo $i: yes \|\| echo $i: n", then one will find that a surprisingly large number of software projects needs to deal with terminal sizes, and thus uses the non-standard SIGWINCH/TIOCGWINSZ approach directly in order to do so! This list is self-explanatory: ahwm.tar_bomb_git/: no alpine.tar_bomb_git/: yes bash.git/: yes busybox.git/: yes cddb.tar_bomb_git/: no cgit.git/: no curl.tar_bomb_git/: no dnsmasq.git/: no dovecot.tar_bomb_git/: yes dropbear.tar_bomb_git/: yes enscript.tar_bomb_git/: no gawk.tar_bomb_git/: no ghostscript.tar_bomb_git/: no git-manpages.tar_bomb_git/: no git.git-no_reduce/: yes gmake.tar_bomb_git-no_reduce/: no gpg1.tar_bomb_git/: no grap.tar_bomb_git/: no groff.tar_bomb_git/: no heirloom-doctools.git/: no idnkit.tar_bomb_git/: no kertex.tar_bomb_git/: yes lcdf-typetools.tar_bomb_git/: no less-fork.git/: yes less.tar_bomb_git/: yes letsencrypt-sh.git/: no libidn.tar_bomb_git/: no libressl.tar_bomb_git/: no lighttpd.tar_bomb_git/: no lua.tar_bomb_git/: no lz4.git/: no mail-apple.tar_bomb_git/: yes mail-netbsd.cvs_bomb_git/: yes mail-openbsd.cvs_bomb_git/: yes mawk.tar_bomb_git/: no mbedtls.tar_bomb_git/: no mdocml.cvs_bomb_git/: no mksh.git/: yes mpop.tar_bomb_git/: no msmtp.tar_bomb_git/: no mutt.tar_bomb_git/: yes nawk.tar_bomb_git/: no ncurses.tar_bomb_git/: yes netpgp.cvs_bomb_git/: no openssh.tar_bomb_git/: yes openssl.git/: no pcc-libs.cvs_bomb_git/: no pcc.cvs_bomb_git/: no perl.tar_bomb_git/: yes plan9port.git/: yes psutils.tar_bomb_git/: no re2.git/: no refind.tar_bomb_git-no_reduce/: no rxvt-unicode.tar_bomb_git/: no NOTE: but uses TIOCSWINSZ! (And assumes calling this ioctl(2) automatically raises SIGWINCH!) schily.tar_bomb_git/: yes screen.tar_bomb_git/: yes sox.tar_bomb_git/: no tin.tar_bomb_git/: yes tinycc.git/: no tre.git/: no vile.tar_bomb_git/: yes vim.tar_bomb_git/: yes wpa_supplicant.tar_bomb_git/: no xfig.tar_bomb_git/: no xorriso.tar_bomb_git/: no

(0003223) steffen (reporter) 2016-05-12 10:42	\|I now see that some implementations output "rows = X; columns = Y;" and some output "rows X; columns Y;" so I'm less in favour of this solution than I was. Since the format of -a isn't defined it is only for informational purposes anyway, and since dimensions are a vivid part i think it should be advertised they should be included. (Granted i don't use it for that, i only use -a for grepping utf in my .profile as part of the local detection. I use -g to save a clean state that i can then use in a terminal reset alias, thanks to Sven Maschek of course, ___a s-treset 'echo "X[4iX[?4iX[?38lX\X(BX)0OX[?5lX[0mX[rX[HX[J" \| tr "XO" "\033\017"; ${___STTY_RESET}' ___STTY_RESET="stty `stty -g`" Works.)

(0003224) kre (reporter) 2016-05-12 11:15 edited on: 2016-05-12 11:17	Re note 3220: None of the systems I've examined have a "size" keyword in the output from "stty -a". No, that's not what "size" is, it is an command line parameter to stty, which results in the current size settings being output, in a very programming friendly way (no parsing required). $ stty size 21 80 Extremely suitable for something like width() { set -- $( stty size ) printf "%s\n" "$2" } W=$( width ) or whatever.

(0003225) shware_systems (reporter) 2016-05-12 13:20	Re: 3219 The latest addition sponsored by other than Open Group, afaict, is IEEE proposing posix_devctl(). The people to convince are the organizations with representatives, IEEE, ISO, or Open Group's BWG, to a) make it a formal work item of that organization with the attendant administrative overhead, in both time and financial senses, and b) sufficient people for a quorum of that organization getting involved enough to say a 'yay'. I suspect many 'nays' are less due to technical merit, but that many people with an interest don't have room on their calendars due to other commitments so a quorum isn't obtainable.

(0003227) shware_systems (reporter) 2016-05-13 13:18	Re: 3217 tput with basic functionality is part of the base utilities, so is an option. Certainly XCurses expects terminfo data to be used in conjunction with it, but for a TERM spec like rxvt-x11 I'd expect it to query an X11 data set for common values like maxlines or maxcols, if the rxvt package does not provide a tic source file or XCurses is not even installed. For those two values simply adding it as discussed is plausible. In the "it would be nice" category: For terminal types that support settings terminfo doesn't, a more generic argument validation method could be defined, possibly as a UPE option, that packages like X11 or a VRML driver, not just XCurses, could hook into. Once defined tput would be a generic query/setter utility for presentation level display aspects and stty would be for transport layer aspects. Stereoscopic and holographic displays and 3D printers come to mind as newer types this would be useful with.

(0003863) geoffclare (manager) 2017-10-19 16:28 edited on: 2017-10-19 16:29	After applying the changes from 0001151, make the following changes: On page 3264 lines 109758-109761 (XCU stty -g) change: -g Write to standard output all the current settings in an unspecified form that can be used as arguments to another invocation of the stty utility on the same system. The form used shall not contain any characters that would require quoting to avoid word expansion by the shell; see Section 2.6 (on page 2353). to: -g Write to standard output all the current settings, optionally excluding the terminal window size, in an unspecified form that, when used as arguments to another invocation of the stty utility on the same system, attempts to apply those settings to the terminal. The form used shall not contain any sequence that would form an Informational Query, nor any characters that would require quoting to avoid word expansions, other than field splitting, by the shell; see Section 2.6 (on page 2353). On page 3264 line 109763 (XCU stty operands) change: The following operands shall be supported to set the terminal characteristics. to: The following operands shall be supported. On page 3269 after line 109976 (XCU stty operands) insert two new operands subsections: Terminal Window Size rows number Set the number of rows in the terminal window size to the number given. cols number Set the number of columns in the terminal window size to the number given. The terminal window size shall be updated as if the stty utility calls tcgetwinsize() to populate a winsize structure, updates one or both of the ws_row and ws_col members according to the rows and cols numbers specified, and then calls tcsetwinsize() with the updated structure (see [xref to XSH tcgetwinsize] and [xref to XSH tcsetwinsize]). Informational Queries size Write the current terminal window size to standard output. On page 3270 line 109999 (XCU stty STDOUT) change: If operands are specified, no output shall be produced. to: If operands are specified and they do not include any Informational Queries, no output shall be produced. If the size operand is specified, stty shall write to standard output the terminal window size as follows: <tt>"%1dΔ%1d\n", <rows>, <columns></tt> where <tt><rows></tt> and <tt><columns></tt> are the number of rows and columns in the terminal window size, respectively. On page 3271 lines 110036-110039 change the example to read: saveterm=$(stty −g) # save terminal state ttysize=$(printf "rows %d cols %d" $(stty size)) # save terminal size stty new settings # set new state ... stty $saveterm # restore terminal state stty $ttysize # restore terminal size

Issue History
Date Modified	Username	Field	Change
2016-05-10 19:12	steffen	New Issue
2016-05-10 19:12	steffen	Name	=> steffen
2016-05-10 19:12	steffen	Section	=> stty, A.8.3
2016-05-10 19:12	steffen	Page Number	=> 3226, 3498
2016-05-10 19:12	steffen	Line Number	=> 108136 ff., 118193 ff.
2016-05-10 22:15	shware_systems	Note Added: 0003203
2016-05-11 09:11	geoffclare	Note Added: 0003204
2016-05-11 10:20	shware_systems	Note Added: 0003205
2016-05-11 10:20	dickey	Note Added: 0003206
2016-05-11 10:30	joerg	Note Added: 0003207
2016-05-11 11:32	steffen	Note Added: 0003208
2016-05-11 11:36	steffen	Note Edited: 0003208
2016-05-11 11:36	joerg	Note Edited: 0003207
2016-05-11 11:37	steffen	Note Edited: 0003208
2016-05-11 20:54	EdSchouten	Note Added: 0003215
2016-05-11 23:13	shware_systems	Note Added: 0003216
2016-05-12 02:23	kre	Note Added: 0003217
2016-05-12 02:24	kre	Note Edited: 0003217
2016-05-12 06:18	stephane	Note Added: 0003218
2016-05-12 06:51	philip-guenther	Note Added: 0003219
2016-05-12 08:36	dickey	Note Added: 0003220
2016-05-12 08:47	dickey	Note Edited: 0003220
2016-05-12 09:50	geoffclare	Note Added: 0003221
2016-05-12 10:27	steffen	Note Added: 0003222
2016-05-12 10:42	steffen	Note Added: 0003223
2016-05-12 11:15	kre	Note Added: 0003224
2016-05-12 11:17	kre	Note Edited: 0003224
2016-05-12 13:20	shware_systems	Note Added: 0003225
2016-05-13 13:18	shware_systems	Note Added: 0003227
2017-06-22 15:04	geoffclare	Relationship added	related to 0001151
2017-10-19 16:28	geoffclare	Note Added: 0003863
2017-10-19 16:29	geoffclare	Note Edited: 0003863
2017-10-19 16:30	geoffclare	Interp Status	=> ---
2017-10-19 16:30	geoffclare	Final Accepted Text	=> Note: 0003863
2017-10-19 16:30	geoffclare	Status	New => Resolved
2017-10-19 16:30	geoffclare	Resolution	Open => Accepted As Marked
2017-10-19 16:31	geoffclare	Tag Attached: issue8
2020-04-23 13:50	geoffclare	Status	Resolved => Applied
2024-06-11 08:56	agadmin	Status	Applied => Closed

Aardvark Mark IV