On 5/14/26 7:56 PM, Robert Elz wrote:
Date: Wed, 13 May 2026 16:56:37 -0400 From: Chet Ramey <[email protected]> Message-ID: <[email protected]>| This assumes that the user's application falls back to something other than | LINES and COLUMNS to determine the appropriate window size. That was not | the case when bash started setting LINES and COLUMNS. That I do not believe for a second. Applications, and I'd expect all of them, have always had a default to use when no other information was available -- the issue was that it wasn't necessarily the default that the users wanted to use.
I really wouldn't be so absolute. I started getting reports about this in 1992, especially for `hybrid' BSD-SysV systems like HP-UX and early AIX. The difference between "not defaulting to anything" and "defaulting to the wrong thing" isn't that great from a user's perspective. You and I were both around back then, but our experiences may have varied. I suspect you spent a little more time with physical terminals on Unix than I did.
When we reached the stage where terminal sizes weren't fixed, but were flexible (ie: window systems) it should have been obvious that LINES and COLUMNS could not possibly work in that environment - sure the user could tell the application what size the "device" is when the application starts, but there is no way for those env vars to be updated after the application has started, unless the application does it for itself.
The X11 `resize' reached a different conclusion. The idea there was that LINES and COLUMNS set the initial window size, since the default termcap entry for xterm was often wrong (65 lines?). Then the application, if it understood SIGWINCH/TIOCGWINSZ (not all did, initially), would track window size changes itself.
the new size .. and if resize (which is and always was a useless tool)
(expressive shrug)
What's more, even though bash (and other shells) are going to great trouble to set LINES and COLUMNS and keep them representing the window size, bash (at least) is not by default exporting those vars, and I personally doubt that many (or perhaps any) users have "export LINES COLUMNS" in their .profile or .bashrc files (or whatever) so most likely, in practice, all that effort to keep the vars up to date is just being wasted.
OK. And yet there are those who choose to.
Certainly no-one who uses the NetBSD shell is asking for some method to set and update the things (they're not using resize either) and yet, everything "just works".
I'm sure that by this time the applications they care about are using tcgetwinsize().
| I don't agree. The initial problem was applications that used LINES and | COLUMNS to set an initial window size, and didn't fall back to anything | else. I don't think there ever was such an application, they just didn't fall back to what the users wanted, mostly as there was no standard (simple) way to determine what to use (which I'm sure was a problem bash has faced as well, different systems needing different methods, though I kind of hope it has never use the resize method of sending magic escape sequences to the device and hoping for an answer).
They would fall back to something that was wrong or some default that was sometimes correct (80x24) but wrong for the users who cared about it. See above about the default xterm termcap entry and its 65 lines. xterm would set TERMCAP in the initial shell environment (and resize could set that, too), but that didn't always do the job. Users tended not to like applications choosing the wrong thing, so they looked for solutions that would accommodate those applications. It was easier and more broadly useful to have the shell track that information.
| I'm saying you have it backwards. The bash behavior is the result of | people asking for it to work with applications that needed it, not | that bash decided to do this and forced applications to go along. Of course, I never expected differently, but "people asking for it" is rarely, of itself, a good reason to do anything - the request needs to be evaluated for sanity, and this one was never rational, environment variables just aren't a technique that can deal with information that can change at any random time.
OK. What do you do with, say, the HP-UX `vi' from that time, which expects LINES and COLUMNS to define the initial window size and then uses TIOCGWINSZ to track window changes? Or the System V on that didn't understand TIOCGWINSZ at all, even if there was kernel support for it? Users' requests that the shell track LINES and COLUMNS so they (or `resize') can export them satisfy their requirements.
it would be much cheaper to have select check the size (even every time around its loop if needed) than to be checking the size after every fg command has finished - select is rare, fg commands are not.
Sure, but bash is already checking the terminal settings after foreground commands anyway, so it knows what to restore if a command exits due to a signal. It's cheap to get the window size along with that. And since checking the window size is optional, we've come full circle to the appropriate default for that option.
ps: what do you do if you're actually using COLUMNS in bash, when the standard input (which readline cares about) is one device, of one width and standard out (which select cares about, I assume) is a different device, of a different width? COLUMNS cannot be both.
By default, readline cares about the true window size, not $COLUMNS. You
can compile bash in a way that setting LINES and COLUMNS modifies
readline's behavior, but it's not built that way by default.
Readline has standard interfaces to set the window size and the input and
output file descriptors, which applications like bash can use if they want.
The input and output default to stdin and stdout, respectively. readline
uses its input stream for terminal operations, including setting the
terminal width if the application chooses not to. There are standard
functions to tell readline to reset its idea of the window size, whether
that means readline calling tcgetwinsize() or the calling application
setting the size.
Calling readline without the stdin attached to a terminal is generally user
error (or me trying to debug something). It's quite rare to call readline
with different stdin and stdout file descriptors.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
