From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23425 invoked from network); 7 Jun 1999 21:59:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Jun 1999 21:59:29 -0000 Received: (qmail 27063 invoked by alias); 7 Jun 1999 21:59:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6513 Received: (qmail 27056 invoked from network); 7 Jun 1999 21:59:21 -0000 From: "Bart Schaefer" Message-Id: <990607215907.ZM19785@candle.brasslantern.com> Date: Mon, 7 Jun 1999 21:59:07 +0000 In-Reply-To: <199906071911.EAA12590@pop1.ngy.3web.ne.jp> Comments: In reply to Tatsuo Furukawa "COLUMNS/LINES environment variable" (Jun 8, 4:13am) References: <199906071911.EAA12590@pop1.ngy.3web.ne.jp> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: Tatsuo Furukawa , zsh-workers@sunsite.auc.dk Subject: Re: COLUMNS/LINES environment variable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 8, 4:13am, Tatsuo Furukawa wrote: > Subject: COLUMNS/LINES environment variable > > This change is executed after zsh-3.0.4 release, and zsh-3.0.5 has > this code. (And this code also included zsh-3.1.5-pws-XX.) > "ChangeLog" file has following entry. This change is made internally > by Zoltan, who is zsh maintainer. This change was not discussed on > the zsh mailing list. So, Zoltan ONLY knows exact reason. I think it was discussed, though perhaps how the code eventually ended up is not reflected in any specific patch. Here are some messages about it (sorry for not having zsh-workers article numbers, I'm searching an experimental archive that happens to be using zsh-workers messages as test cases but doesn't spit out the X- headers yet): Date Sender Subject 03/30/97 zefram@dcs.warwick.ac.uk setting window size 03/31/97 zefram@dcs.warwick.ac.uk window size bugfix 05/18/97 hzoli@ny.frontiercomm.net More LINES/COLUMNS changes 05/10/97 schaefer@candle.brasslantern.com Re: test patches 05/10/97 hzoli@ny.frontiercomm.net Re: test patches 12/09/97 schaefer@brasslantern.com zsh 3.0.5 WINSZ stuff is messing up my vi 12/09/97 schaefer@brasslantern.com PATCH: 3.0.5: terminal size should not be reset by zsh -c > But now zsh does not act such that. Current zsh receives SIGWINCH, > but it does not change COLUMNS/LINES environment variable. 3.0.5 doesn't even change the internal lines/columns on WINCH. (We had this conversation last October.) > I think this is just a bug. The export should probably have occurred when the internal lines/columns are updated. I didn't put that into the patch that started recognizing SIGWINCH again. > Then, I want to propose the feature for terminal size. > > 1. Following three value is ALWAYS same. > > - Environment variable COLUMNS/LINES. > - Shell variable COLUMNS/LINES. > - The value held by TIOCGWINSZ. There's an additional source of lines/columns information: The terminal information database (either termcap or terminfo). The problem with asserting "value is ALWAYS same" is that, at shell startup, you may have three conflicting values for terminal size. Any one of them may be wrong in various circumstances, and it's difficult/impossible to cause the term{cap,info} one to change. Which one do we believe? > 2. When starting zsh, terminal size are set by environment variable > COLUMNS/LINES. > > 3. When user sets value into COLUMNS/LINES explicitly, zsh also set > TIOCSWINSZ. The startup code in init.c calls adjustwinsize(0), which means "believe the environment first, and if that produces zero, then (if TIOCGWINSZ works) believe the terminal driver or (otherwise) termcap." However, we still don't know which of those was actually correct, so we do not impose the environment on the terminal driver unless LINES/COLUMNS are explicitly set [adjustwinsize(2) or adjustwinsize(3)]. > 4. When user sets 0 to COLUMNS/LINES, zsh measures terminal size (by > TIOCGWINSZ), and sets it. > > 5. When COLUMNS/LINES is "unset", COLUMNS/LINES are deleted. > > 6. When terminal is resized (by mouse), zsh measures terminal size, > and sets LINES/COLUMNS. These should all be happening, except for the oversight about exporting LINES/COLUMNS. > 7. After some command is executed, zsh measures terminal size, and > sets LINES/COLUMNS. This is where we ran into trouble before. "After some command" you are back in the same boat as you are at shell startup -- you have no idea if the terminal was resized during the external command or if the tty driver values for lines/columns have simply been wrong all along. So we chose to do nothing (again unless COLUMNS/LINES give no information). Probably in that last case we could see whether the tty driver values of lines/columns actually changed since the last TIOCGWINSZ, and elect to believe them in that event. The correct course for the user is to explicitly set LINES/COLUMNS if he knows the correct values [e.g. eval $(resize)] or to unset them if he knows that the terminal driver has the right values. (Hmm, there isn't any way to assert that the termcap entry is correct ....) We should document this somewhere, at least in the FAQ, and fix any export issues.