* COLUMNS/LINES environment variable
@ 1999-06-07 19:13 Tatsuo Furukawa
1999-06-07 21:59 ` Bart Schaefer
0 siblings, 1 reply; 4+ messages in thread
From: Tatsuo Furukawa @ 1999-06-07 19:13 UTC (permalink / raw)
To: zsh-workers
Hello, zsh developers.
I have a complaint for following zsh action.
1. When terminal is resized, COLUMNS/LINES shell variable is changed
(that's OK), but COLUMNS/LINES environment variable is NOT changed.
This means that there is a difference between shell variable and
environment variable. [zsh-3.1.5-pws20, zsh-3.0.6-pre4]
2. COLUMNS/LINES cannot be exported. "export COLUMNS" command is
void. [zsh-3.0.6-pre4]
3. COLUMNS/LINES seems to be exported. But it doesn't. "export
COLUMNS" command changes COLUMNS environment variable ONLY once.
When terminal size is changed again, COLUMNS environment variable
is not changed. [zsh-3.1.5-pws20]
Ancient zsh does not act so.
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.
>> Tue Sep 16 04:43:25 1997 Zolt.. Hidv..i <hzoli@cs.elte.hu>
>>
>> * Src/zle_tricky.c: Show explanation if there are no or more
>> than one possible completions.
>>
>> * Src/glob.c: Glob after ((#)) with extendedglob set caused
>> a coredump
>>
>> * Src/builtin.c: read -k sometimes caused a coredump
>>
>> * Src/jobs.c, Src/init.c, Src/params.c, Src/signals.c,
>> Src/utils.c: Setting LINES and COLUMNS manually now works,
>> and it is equivalent to stty rows and stty columns.
According this log, it seems that he just wanted to be same "stty
columns/lines" and "LINES/COLUMNS". Because ancient zsh has a feature
that LINES/COLUMNS are set when stty rows/columns is executed.
NOTE: This is executed as follows:
1. stty rows/columns is executed.
2. SIGWINCH is invoked.
3. zsh recieves SIGWINCH.
4. COLUMNS/LINES is changed.
But now zsh does not act such that. Current zsh receives SIGWINCH,
but it does not change COLUMNS/LINES environment variable.
I think this is just a bug. Because there is NO reason for deleting
this feature. And ksh/sh/bash/etc... has this feature, so zsh should
has it too! I beleve that it is needed for zsh users. (Zoltan, if you
read this mail, please comment it!)
------------------------------------------------------------------------------
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.
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.
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.
7. After some command is executed, zsh measures terminal size, and
sets LINES/COLUMNS.
------------------------------------------------------------------------------
And here is the patch for realizing this proposal. :-)
This patch is for zsh-3.1.5-pws20. I can make this patch for
zsh-3.0.6-pre4.
diff -urb zsh-3.1.5-pws-20/Src/utils.c zsh-3.1.5-pws-20-modified/Src/utils.c
--- zsh-3.1.5-pws-20/Src/utils.c Mon May 17 00:32:15 1999
+++ zsh-3.1.5-pws-20-modified/Src/utils.c Tue Jun 8 03:59:59 1999
@@ -865,30 +865,46 @@
adjustwinsize(int from)
{
int oldcols = columns, oldrows = lines;
+ int term_columns = 0, term_lines = 0;
+ static int adjusting = 0;
+ int size_changed = 0;
#ifdef TIOCGWINSZ
- static int userlines, usercols;
-
if (SHTTY == -1)
return;
+#endif /* TIOCGWINSZ */
- if (from == 2)
- userlines = lines > 0;
- if (from == 3)
- usercols = columns > 0;
+ /* To prevent recursion */
+ if (adjusting)
+ return;
+ adjusting = 1;
+
+#ifdef TIOCGWINSZ
if (!ioctl(SHTTY, TIOCGWINSZ, (char *)&shttyinfo.winsize)) {
- if (!userlines || from == 1)
- lines = shttyinfo.winsize.ws_row;
- if (!usercols || from == 1)
- columns = shttyinfo.winsize.ws_col;
+ term_lines = shttyinfo.winsize.ws_row;
+ term_columns = shttyinfo.winsize.ws_col;
}
+
+ if ((from == 0) || (from == 1)) {
+ lines = term_lines;
+ columns = term_columns;
+ }
+
+ if ((from == 2) && (lines <= 0))
+ lines = term_lines;
+ if ((from == 3) && (columns <= 0))
+ columns = term_columns;
#endif /* TIOCGWINSZ */
+
+ /* When lines/columns are invalid value... */
if (lines <= 0)
lines = tclines > 0 ? tclines : 24;
if (columns <= 0)
columns = tccolumns > 0 ? tccolumns : 80;
+
+ /* setting termflags */
if (lines > 2)
termflags &= ~TERM_SHORT;
else
@@ -898,18 +914,37 @@
else
termflags |= TERM_NARROW;
+
#ifdef TIOCGWINSZ
- if (interact && from >= 2) {
+ if (interact && (lines != term_lines || columns != term_columns)) {
shttyinfo.winsize.ws_row = lines;
shttyinfo.winsize.ws_col = columns;
ioctl(SHTTY, TIOCSWINSZ, (char *)&shttyinfo.winsize);
+ size_changed = 1;
}
#endif
- if (zleactive && (from >= 2 || oldcols != columns || oldrows != lines)) {
+ if (interact) {
+ if (oldcols != columns) {
+ if (getsparam("COLUMNS")) { /* check whether "COLUMNS" is exist or not */
+ setiparam("COLUMNS", columns);
+ size_changed = 1;
+ }
+ }
+ if (oldrows != lines) {
+ if (getsparam("LINES")) { /* check whether "LINES" is exist or not */
+ setiparam("LINES", lines);
+ size_changed = 1;
+ }
+ }
+ }
+
+ if (zleactive && size_changed) {
resetneeded = winchanged = 1;
zrefresh();
}
+
+ adjusting = 0;
}
/* Move a fd to a place >= 10 and mark the new fd in fdtable. If the fd *
--
Tatsuo Furukawa (frkwtto@osk3.3web.ne.jp)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: COLUMNS/LINES environment variable 1999-06-07 19:13 COLUMNS/LINES environment variable Tatsuo Furukawa @ 1999-06-07 21:59 ` Bart Schaefer 1999-06-09 17:13 ` Tatsuo Furukawa 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 1999-06-07 21:59 UTC (permalink / raw) To: Tatsuo Furukawa, zsh-workers 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: COLUMNS/LINES environment variable 1999-06-07 21:59 ` Bart Schaefer @ 1999-06-09 17:13 ` Tatsuo Furukawa 1999-06-09 18:08 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Tatsuo Furukawa @ 1999-06-09 17:13 UTC (permalink / raw) To: zsh-workers; +Cc: schaefer Sorry for late reply, and thank for response. Bart> I think it was discussed, Oh, sorry. Before I wrote the mail, I searched zsh mail archive, but my range was narrow.... Bart> Here are some messages about it Thank you! I can catched up reading these messages. Bart> (sorry for not having zsh-workers article numbers Please don't mind. Your information is perfect. I could get the messages from zsh-workers archive. And, I added article numbers. :-) Date No Subject 03/30/97 3053 zefram setting window size 03/31/97 3063 zefram window size bugfix 05/10/97 3114 schaefer Re: test patches 05/10/97 3119 hzoli Re: test patches 05/18/97 3156 hzoli More LINES/COLUMNS changes 12/09/97 3648 schaefer zsh 3.0.5 WINSZ stuff is messing up my vi 12/09/97 3649 schaefer PATCH: 3.0.5: terminal size should not be reset by zsh -c Bart> 3.0.5 doesn't even change the internal lines/columns on WINCH. Bart> (We had this conversation last October.) Yes, I remember. (And I forgot to add this.) Current zsh code is applied following patch. This comes from zsh-workers/4447. >> Index: Src/utils.c >> --- utils.c Sat May 23 08:53:31 1998 >> +++ - Sat Oct 24 11:36:47 1998 >> @@ -855,9 +855,9 @@ >> usercols = columns > 0; >> >> if (!ioctl(SHTTY, TIOCGWINSZ, (char *)&shttyinfo.winsize)) { >> - if (!userlines) >> + if (!userlines || from == 1) >> lines = shttyinfo.winsize.ws_row; >> - if (!usercols) >> + if (!usercols || from == 1) >> columns = shttyinfo.winsize.ws_col; >> } >> #endif /* TIOCGWINSZ */ This patch makes zsh stranger than original 3.0.5. Because, environment variable COLUMNS/LINES are different from shell variable. Users can check COLUMNS/LINES using "echo $COLUMNS", but their application may not receive that value. (Environment variable $COLUMNS are passed to their application.) Bart> (We had this conversation last October.) Yes. Your advice (TRAPWINCH() { eval $(resize) }) WAS very valuable for me. But it is not work at following case: 1. Rlogin remote host 2. Change terminal size 3. (Then, COLUMNS/LINES are set to correct value) 4. Exit from remote host 5. COLUMNS/LINES are old value! This phenomenon is NOT appeared by another shell. My dissatisfaction is "Why ONLY zsh can not?". And my hope is "Other shell can do it. So, zsh can do it too!". Bart> There's an additional source of lines/columns information: The Bart> terminal information database (either termcap or terminfo). Oh, I forgot. But termcap/terminfo value is not important for resizable terminal. This value should be used for the last resort for measureing terminal size, I think. (And zsh already does.) Bart> The problem with asserting "value is ALWAYS same" is that, at Bart> shell startup, you may have three conflicting values for Bart> terminal size. Any one of them may be wrong in various Bart> circumstances, and it's difficult/impossible to cause the Bart> term{cap,info} one to change. Which one do we believe? This problem is exist in ALL terminal related programs. So, I investigated some programs. [ vi ($Revision: 78.2.1.8 $ HP-UX 10.20) ] When startup, 1. If COLUMNS/LINES are exist, this value is used. If terminal is resized, TIOCGWINSZ value is used (COLUMNS/LINES are ignored). 2. If COLUMNS/LINES are not exist, TIOCGWINSZ value is used. If terminal is resized, TIOCGWINSZ value is used. [ less (Version 3.3.2 HP-UX 10.20) ] When startup, 1. If COLUMNS/LINES are exist, this value is used. If terminal is resized, COLUMNS/LINES is STILL used (terminal is resized, but less is NOT resized). 2. If COLUMNS/LINES are not exist, TIOCGWINSZ value is used. If terminal is resized, TIOCGWINSZ value is used. [POSIX shell (HP-UX 10.20)] When startup, (same as vi) >From this result, my recommendation is as follows: [Zsh (I hope...)] When startup, 1. If COLUMNS/LINES are exist, use this value. 2. If above is void, use TIOCGWINSZ value. 3. If above is void, use termcap/terminfo value. 4. If above is void, use 80*25. When resized, 1. TIOCGWINSZ value is used. (Even if COLUMNS/LINES are exist.) I> 7. After some command is executed, zsh measures terminal size, and I> sets LINES/COLUMNS. Bart> "After some command" you are back in the same boat as you are at Bart> shell startup -- you have no idea if the terminal was resized Bart> during the external command or if the tty driver values for Bart> lines/columns have simply been wrong all along. How about this? "After some command", 1. If COLUMNS/LINES are different from internal columns/lines value, COLUMNS/LINES are used. 2. If above is void, use TIOCGWINSZ value. Note that When COLUMNS/LINES are used, zsh issues TIOCSWINSZ. So, once zsh is started, COLUMNS/LINES and TIOCGWINSZ are same. Bart> Probably in that last case we could see whether the tty driver Bart> values of lines/columns actually changed since the last Bart> TIOCGWINSZ, and elect to believe them in that event. Your idea is also good for me. :-) Bart> So we chose to do nothing (again unless COLUMNS/LINES give no Bart> information). If this policy is still not changed, could you add some options? Like this: >> setopt autotermresize zsh measures terminal size and >> sets COLUMNS/LINES. >> unsetopt autotermresize zsh does not measure terminal size, >> user must set COLUMNS/LINES manually. >> >> If you want to act like POSIX shell, set autotermresize. Bart> The correct course for the user is to explicitly set Bart> LINES/COLUMNS if he knows the correct values [e.g. eval Bart> $(resize)] or to unset them if he knows that the terminal driver Bart> has the right values. This has following inconvenience: 1. The script/program which uses COLUMNS/LINES and don't use TIOCSWINSZ is not work well. 2. When user execute "eval $(resize)" accidentally, zsh will not change terminal size. 3. My linux/HP-UX system gives LINES/COLUMNS when I logged in. So, I must unset LINES/COLUMNS explicitly. If you think the user If user have to tell "terminal driver has the right values" to zsh, will you change the way? ("unset LINES/COLUMNS method" has the problem. How about setopt? (like autotermresize)) Bart> We should document this somewhere, at least in the FAQ, and fix Bart> any export issues. That's nice! If export issues is fixed, my dissatisfaction will be reduced undoubtedly. -- Tatsuo Furukawa (frkwtto@osk3.3web.ne.jp) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: COLUMNS/LINES environment variable 1999-06-09 17:13 ` Tatsuo Furukawa @ 1999-06-09 18:08 ` Bart Schaefer 0 siblings, 0 replies; 4+ messages in thread From: Bart Schaefer @ 1999-06-09 18:08 UTC (permalink / raw) To: Tatsuo Furukawa, zsh-workers On Jun 10, 2:13am, Tatsuo Furukawa wrote: } Subject: Re: COLUMNS/LINES environment variable } } Current zsh code is } applied following patch. This comes from zsh-workers/4447. [...] } This patch makes zsh stranger than original 3.0.5. Because, } environment variable COLUMNS/LINES are different from shell variable. Yes, as I said, this was an oversight. When LINES/COLUMNS are assigned, adjustwinsize() is called before the export step. This makes fixing the bug more complicated, because adjustwinsize() can't do the export itself when the reason for the call is that LINES/COLUMNS are changing. The other complication is that the current code resets the (internal) value of COLUMNS when LINES is assigned, and vice versa, but again does not peform the export. Tatsuo's patch handles the export, but I think it's actually bad that assigning to either of LINES/COLUMNS causes both of them to change. (This gets tricky because the tty driver's idea of the rows/columns shouldn't get messed up either, but of course the only way to set either of those is to set both.) Oh, and if somebody can tell me why zrefresh() has to be called even when the new values are the same as the old ones, I'd appreciate knowing. } [ vi ($Revision: 78.2.1.8 $ HP-UX 10.20) ] } } When startup, } } 1. If COLUMNS/LINES are exist, this value is used. If terminal is } resized, TIOCGWINSZ value is used (COLUMNS/LINES are ignored). } } 2. If COLUMNS/LINES are not exist, TIOCGWINSZ value is used. If } terminal is resized, TIOCGWINSZ value is used. vim (Vi IMproved 5.3) uses the TIOCGWINSZ values at startup but then reverts to COLUMNS/LINES any time an external program is run (e.g. via a shell escape). This annoys the heck out of me, because I frequently start my mail GUI from an 80x24 xterm and then launch an 80x48 xterm from there to edit messages -- which means LINES is wrong. } [POSIX shell (HP-UX 10.20)] } } (same as vi) I suppose we could actually go so far as to test at configure time for a POSIX environment (say, the same check that's now used to find out if we have POSIX termios) and define a constant that could be used to tell if zsh can always believe TIOCGWINSZ. } When startup, } } 1. If COLUMNS/LINES are exist, use this value. } 2. If above is void, use TIOCGWINSZ value. } 3. If above is void, use termcap/terminfo value. } 4. If above is void, use 80*25. I'm sticking with 80x24, but otherwise I agree, and this should be what presently happens (at startup). } When resized, } } 1. TIOCGWINSZ value is used. (Even if COLUMNS/LINES are exist.) Yes. I believe we can assume that if SIGWINCH is sent/received, then the tty driver has valid numbers. The important point is that COLUMNS/LINES should also be exported if they are in the environment, which is what is not happening yet. } "After some command", } } 1. If COLUMNS/LINES are different from internal columns/lines } value, COLUMNS/LINES are used. No, that can't be right. No external command can modify COLUMNS/LINES in zsh's environment, so the only way the environment could be different is if the internal values were previously read from the tty, in which case it would be wrong to go back. } Bart> Probably in that last case we could see whether the tty driver } Bart> values of lines/columns actually changed since the last } Bart> TIOCGWINSZ, and elect to believe them in that event. } } Your idea is also good for me. :-) That's the one I've been fooling with. See remarks above about the complications. } Bart> The correct course for the user is to explicitly set } Bart> LINES/COLUMNS if he knows the correct values [e.g. eval } Bart> $(resize)] or to unset them if he knows that the terminal driver } Bart> has the right values. } } This has following inconvenience [...] Actually, explicitly assigning them a value of zero will force zsh to read the values from the tty driver, which is then correctly exported. So instead of "eval $(resize)" just "LINES=0 COLUMNS=0" will fix it. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-06-09 18:09 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-07 19:13 COLUMNS/LINES environment variable Tatsuo Furukawa 1999-06-07 21:59 ` Bart Schaefer 1999-06-09 17:13 ` Tatsuo Furukawa 1999-06-09 18:08 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).