Re: [doc] LINES/COLUMNS auto-update in non-interactive shells contradicts manual

On 5/11/26 5:30 PM, Robert Elz wrote:
>      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.

This breaks down in the face of SIGWINCH, especially when it is sent to
a child process while job control is active, and the shell doesn't
receive it.

Since bash uses COLUMNS (for select, if you disregard everything else),
it is an unnecessary burden for the user to have to manually reset
COLUMNS after a window size change. That's the whole rationale for
`checkwinsize' to exist.

> 
> The standard is quite clear:
> 
> 	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

This assumes that something will change LINES and COLUMNS in response to
changes to `the terminal characteristics'. The standard assumes those are
immutable (especially with its reference to $TERM), but reality is
different.

> 
> Shell(s) are supposed to be conforming applications.   bash shouldn't (ever)
> be setting those variables. 

Except that we live in 2026, not 1992. That language has survived
essentially unchanged since the first issue of 1003.2, but expectations
have changed.


> That bash needs to know the sizes for readline is irrelevant.

Sure, ok, then how about `select'? Or other applications that use LINES
and COLUMNS as they appear in the environment and expect them to be
accurate? Why should the shell leave this burden up to the user?


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

This is true.

-- 
``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/