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.
Back in the very early days, when output devices (terminals, etc) were
each some fixed size, which couldn't change - but not all the same size,
then using LINES & COLUMNS as a way for the user to tell the application
what size to use made sense - and what's more was in line with the definitions
of those variables. The user is using them to override the default that
the application would otherwise use, which is what they were designed for,
and what they should still be used for.
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.
That means, when the application detects that the window size has changed
it needs to get the new size information, and make use of it (updating the
environment would be one use it might make, but adjusting its output
formatting using the new values, which don't need to go through the
env vars, is a more useful thing to do, if it ever used the device size
for that purpose).
But that means there must be some method for the application to discover
the new size .. and if resize (which is and always was a useless tool)
can do it, any other application can use the same method to do the same,
though one would hope there would be a better way than that.
Once applications are able to determine the device size, it is patently
obvious that they don't need to be told, via LINES and COLUMNS, what that
size is, though they do need to check for those vars, and accept the user's
request when they are set.
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. 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".
As for select - certainly, select (like every other similar application)
should look (in its case) to see if COLUMNS is set, and if so, use it.
But I'm sure it has some fallback method for when it isn't set, doesn't it?
That method might be stupid (just use 80), or it might attempt to determine
the appropriate size before finally falling back to something like that
when no other info is available, but there must be a method. It doesn't
need COLUMNS to be set to work, or it wouldn't work in non-interactive
shells, or shells where checkwinsize is turned off (never on from the start,
as in "bash +O checkwinsize", though it appears that even in that case,
bash is setting COLUMNS and LINES, but at least after unsetting them, they
remain unset, and to no-one's surprise, in that state, select still works,
it really doesn't demand that COLUMNS be set!)
So while, as I said in the first message, I know there are backward compat
issues with simply removing the update of them, I also suspect that the
need for that is largely illusory ("bash does it, so clearly I need it to
be done" kind of thing) - and select could easily be made smarter than it
appears, and use the same mechanism that checkwinsize uses to see if it
can determine a width, when it finds COLUMNS unset.
I'd also note, that the description of select in the bash manual says nothing
at all about COLUMNS, it is just the description of COLUMNS that happens to
note that select uses it which of course, if it is set, so it should.
Nothing there says that COLUMNS needs to be set for select to operate.
| 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).
| And some others (mksh) do. Those other shells probably don't have the
| burdens of earlier eras.
yash doesn't, the others are all old enough that they do, bosh's origins
even predate ksh after all (it started as the Sys V shell, which was just
a step up from the Sys III shell). ash dates from way way back as well,
contemporary with bash I'd expect.
And you're right, I do blame David Korn for much of what has gone awry
with some shells, some of his inventions are horrid, select among them,
and this is most likely another of them, and explains why all the ksh variants,
and others that have copied that, attempt to do something like this, but
even POSIX, with their initial "ksh is the definition of what a shell should
do" didn't fall into this trap.
| 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.
| And now users have expectations that bash will continue to behave as
| it has.
I'll admit that the users (or some of them) might believe this is required,
but I also expect that they don't really need that at all, and they'd be
quite content (perhaps never even notice) if it simply stopped happening.
After all, most probably aren't exporting the vars, and in that case, all
the updating is doing is wasting bash's cpu time - 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.
kre
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.
