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
0001053 [1003.1(2013)/Issue7+TC1] Shell and Utilities Editorial Enhancement Request 2016-05-10 19:12 2017-06-22 15:04
Reporter steffen View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name steffen
User Reference
Section stty, A.8.3
Page Number 3226, 3498
Line Number 108136 ff., 118193 ff.
Interp Status ---
Final Accepted Text
Summary 0001053: Add a "size" mode to stty(1)
Description I may have overseen something.
But i think it is currently impossible to get access to the real terminal width and height of the terminal from shell scripts, since $COLUMNS and $LINES are not exported.
Many implementations of stty(1), especially of all free Unix clones (that are known to me), support a "size" query which returns the numbers as two space-separated decimal numbers.
I think this should be standardized.
Desired Action After line 3226, add a new list "Special settings" and add an initial item

  Print the number of rows and columns of the terminal as two space-separated decimal integers.

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.


  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 size can be queried with the stty utility.
Tags No tags attached.
Attached Files

- Relationships
related to 0001151New 1003.1(2016)/Issue7+TC2 Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size 

-  Notes
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.
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.
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.
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
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?

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
  ?0[steffen@wales ]$ tput cols
  ?0[steffen@wales ]$ tput lines cols
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
  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

  Print the number of terminal lines in the format specified for [link]$LINES[/].
  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.


  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.

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.
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.
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.

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.
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?
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.

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.
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
 (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
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`"

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

             set -- $( stty size )
             printf "%s\n" "$2"

        W=$( width )

or whatever.

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.
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.

- 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

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