From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@euclid.skiles.gatech.edu>
Received: (qmail 4757 invoked from network); 15 Mar 1997 01:46:05 -0000
Received: from euclid.skiles.gatech.edu (list@130.207.146.50)
  by coral.primenet.com.au with SMTP; 15 Mar 1997 01:46:05 -0000
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id UAA03633; Fri, 14 Mar 1997 20:28:49 -0500 (EST)
Resent-Date: Fri, 14 Mar 1997 20:28:49 -0500 (EST)
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
Message-Id: <970314172949.ZM7467@candle.brasslantern.com>
Date: Fri, 14 Mar 1997 17:29:49 -0800
Reply-To: schaefer@nbn.com
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: zsh-workers@math.gatech.edu
Subject: Fix needed for new COLUMNS/LINES handling
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"a2WT3.0.fu.GjVAp"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/2992
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

My contribution to the several recent display-handling patches for 3.0.3
and 3.1.x included, among other things, two changes:

(1) Make setintenv() call the pm.ifn routine when changing the parameter;
(2) Use setintenv() to establish $COLUMNS and $LINES in init.c.

I recently installed zsh-3.0.3-test4 with these patches added.  Today I
got this message:

---------- Forwarded message ----------
Subject: New unpleasantness w/zsh

This started happening to me in emacs shell buffers:

  aztec [~/zanshin/src/mac/genesis/rsrc] 99 % ls
  ls: ignoring invalid width in environment variable COLUMNS: 0

after the new zsh was installed.  Any ideas?
----------

I'm not sure whether this means that zsh is exporting COLUMNS and LINES
when it did not do so before, or merely that it is exporting a value that
it did not previously export.  In any case, exporting COLUMNS=0 is a bug.
The absolute minimal fix is to change setintenv():

  /**/
  void
  setintenv(char *s, long val)
  {
      Param pm;
      char buf[DIGBUFSIZE];
  
      if ((pm = (Param) paramtab->getnode(paramtab, s)) && pm->env) {
  	(pm->sets.ifn)(pm, val);
- 	sprintf(buf, "%ld", val);
+ 	sprintf(buf, "%ld", (pm->gets.ifn)(pm));
  	pm->env = replenv(pm->env, buf);
      }
  }

This ought to be done anyway, so that any change to "val" made by sets.ifn
is properly picked up by setintenv.  (Question ... is pm->data guaranteed
to be a (long *) in this case?)

However, we also might want to consider changing init.c so that it does
not modify COLUMNS and LINES at all when the winsize.ws_col or .ws_row
values are zero.  There are cases where values for those variables that
are already in the environment may be more correct.

Final question:  Who is responsible for actually exporting LINES and
COLUMNS?  setintenv() is a no-op if pm->env is false, which means that
COLUMS and LINES won't get set if they aren't already exported.  Is
that really how it should behave?  Or is there something else I missed
that my init.c change has broken?