From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22454 invoked from network); 19 Dec 2003 00:55:20 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 19 Dec 2003 00:55:20 -0000 Received: (qmail 20547 invoked by alias); 19 Dec 2003 00:55:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19322 Received: (qmail 20460 invoked from network); 19 Dec 2003 00:55:12 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 19 Dec 2003 00:55:12 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [167.160.213.139] by sunsite.dk (MessageWall 1.0.8) with SMTP; 19 Dec 2003 0:55:12 -0000 Received: from aztec.zanshin.com (IDENT:schaefer@aztec.zanshin.com [167.160.213.132]) by moonbase.zanshin.com (8.12.9/8.12.9) with ESMTP id hBJ0tB0q028498 for ; Thu, 18 Dec 2003 16:55:11 -0800 Date: Thu, 18 Dec 2003 16:55:10 -0800 (PST) From: Bart Schaefer To: zsh-workers@sunsite.dk Subject: Thread developing on austin-group about LINES/COLUMNS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I read it that this suggests that zsh is currently not POSIX-compliant with respect to LINES/COLUMNS. The proposed change to the standard would be closer to zsh's behavior, but would require those variables to lose their auto-update behavior in the event that they are explicitly assigned, which I do not believe zsh presently provides for. ---------- Forwarded message ---------- Date: Thu, 18 Dec 2003 16:34:15 -0800 From: Jason Zions To: Paul Eggert , David Korn Cc: austin-group-l@opengroup.org Subject: RE: LINES and COLUMNS variables Resent-Date: 19 Dec 2003 00:34:45 -0000 Resent-From: austin-group-l@opengroup.org Resent-To: austin-group-l@opengroup.org Bummer. I seem to recall this is pretty common (and useful) behavior. -----Original Message----- From: Paul Eggert [mailto:eggert@twinsun.com] Sent: Thursday, December 18, 2003 4:17 PM To: David Korn Cc: austin-group-l@opengroup.org Subject: Re: LINES and COLUMNS variables At Thu, 18 Dec 2003 09:59:20 -0500 (EST), David Korn writes: > Is a shell that changes the value of LINES and/or COLUMNS when the > window size changes a conforming shell? I'd say no. says "The implementation adds or changes environment variables named in IEEE Std 1003.1-2001 only as specified in IEEE Std 1003.1-2001." The standard doesn't say that the shell changes the value of LINES and/or COLUMNS, so a conforming shell cannot change them. ---------- Forwarded message ---------- Date: Thu, 18 Dec 2003 16:45:08 -0800 From: Bruce Korb To: Paul Eggert Cc: David Korn , austin-group-l@opengroup.org Subject: Re: LINES and COLUMNS variables Resent-Date: 19 Dec 2003 00:47:35 -0000 Resent-From: austin-group-l@opengroup.org Resent-To: austin-group-l@opengroup.org Paul Eggert wrote: > > At Thu, 18 Dec 2003 09:59:20 -0500 (EST), David Korn writes: > > > Is a shell that changes the value of LINES and/or COLUMNS when > > the window size changes a conforming shell? > > I'd say no. > > says "The implementation adds or changes environment variables named > in IEEE Std 1003.1-2001 only as specified in IEEE Std 1003.1-2001." > The standard doesn't say that the shell changes the value of LINES > and/or COLUMNS, so a conforming shell cannot change them. Cool. Let's change the standard. The primary purpose of the standard is to specify a workable set of requirements that conform to most current implementations. The whole idea behind the LINES and COLUMNS is to make it possible work with text screens of sizes that differ from 24X80. Now, that said, it can be reasonably argued that if someone says, ``COLUMNS=132'' then the shell should not willy-nilly go changing it automatically. There are already some variables that are in some sense magical and they lose their magic when they are explicitly assigned to. Treating these two as magical would make sense: a conforming implementation ought to be able to set and alter them until somebody goes and makes an explicit assignment. Making it necessary for users to know how to configure functions to handle resizing automatically puts too much of a burden on them. I hate it when vi thinks my screen size is different from what it is. Dynamic LINES and COLUMNS is better for a human usable interface perspective. Regards, Bruce