COLUMNS/LINES environment variable

COLUMNS/LINES environment variable

[Tatsuo Furukawa]

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)

Re: COLUMNS/LINES environment variable

[Bart Schaefer]

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.

Re: COLUMNS/LINES environment variable

[Tatsuo Furukawa]

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)

Re: COLUMNS/LINES environment variable

[Bart Schaefer]

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