Robert Elz wrote in
<[email protected]>:
| Date: Mon, 11 May 2026 16:06:15 -0400
| From: Zachary Santer <[email protected]>
| Message-ID: <CABkLJU+7m6zDRM1b1oKehYVf-c2A7fwKwXRx7kmRGtoMqxg_Ag@mail.\
| gmail.com>
|
|| On Mon, May 11, 2026 at 3:18���PM Chet Ramey <[email protected]> wrote:
||> More people than not have expressed a desire to have LINES and COLUMNS
||> reflect the true window size.
||
|| Huh? Yeah, I would be one of those people.
|
|I wouldn't. That is not what LINES and COLUMNS are intended to be
|(or ever were). They're supposed to be a method for the user to
|override the default settings for length/width, not a method to find
|out what the default settings are.
|
|The standard is quite clear:
POSIX.1-2024 adds "size" request to stty(1):
$ stty size
55 191
| Users and conforming applications should not set LINES unless
| they wish to override the system selection and produce output
| unrelated to the terminal characteristics.
|
|There is essentially identical wording about COLUMNS
|
|Shell(s) are supposed to be conforming applications. bash shouldn't \
|(ever)
|be setting those variables. Of course, we know it does, and backwards \
|compat
|is going to cause it to keep doing that. It was always a mistake, \
|but most
|likely one that can't be fixed (except by switching to an unbroken shell,
|dash wouldn't do that...)
|
|That bash needs to know the sizes for readline is irrelevant.
|
|And of course, this fork of the original message has nothing to do with
|it being a mistake for a script to ever use LINES or COLUMNS (or a whole
|bunch of other variables) for uses other than those defined. Imagine
|what would happen were the script to use HOME or similar as a general
|variable?
Off-topic but for the MUA i went "over great lengths" (if that is
the term) to end up with
COLUMNS The user’s preferred width in column positions for the terminal
screen. Queried and used once on program startup in interac‐
tive or batch (-#†) mode on a (pseudo-) terminal. Actively
managed (‘SIGWINCH’) for child processes and the MLE† (Terminal
control and line editor†) in interactive mode thereafter. Non-
interactive mode always uses, and the fallback default is a
compile-time constant, by default 80 columns. If in batch mode
(on (pseudo-) terminal) COLUMNS and LINES† are both set but not
both are usable (empty, not a number, or 0) at program startup,
then the real terminal screen size will be (tried to be) deter‐
mined once. (Normally the SHELL† manages these variables, and
unsets them for pipe specifications etc.) Also see cols†.
a.k.a. i ended up adding a "cols" variable because in effect
i sometimes want "the full of" $COLUMNS (header summary for
example), but then again often not (when reading an email, those
web ui users simply write superlong lines without folding, and
then those do not even use format=flowed, .. though that i do not
support yet, but still ..).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
