TERMCAP problem.

TERMCAP problem.

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

I'm using zsh V3.1.9 and termcap V1.3 on SunOS se9ws265 5.6 Generic_105181-03
sun4u sparc
I try to use screen and zsh.  Screen sets the TERMCAP variable to the
capabilities, and not to a file containing the capabilities.  If zsh is launched
in this environment, it core dumps, because at a certain moment getenv("TERM")
returns 0 and this is fed into a strcmp.

Do I do something wrong ??

Please, reply to mailto:koen.van_hoof@alcatel.be, because I cannot subscribe to
the mailing list. (It returns a mail "failure notice")

--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

Re: TERMCAP problem.

[Dan Nelson]

In the last episode (Jan 15), koen van hoof said:
> I'm using zsh V3.1.9 and termcap V1.3 on SunOS se9ws265 5.6 Generic_105181-03
> sun4u sparc
> I try to use screen and zsh.  Screen sets the TERMCAP variable to the
> capabilities, and not to a file containing the capabilities.  If zsh is launched
> in this environment, it core dumps, because at a certain moment getenv("TERM")
> returns 0 and this is fed into a strcmp.

getenv("TERM") should never return 0.  screen sets both TERM and
TERMCAP on all my machines.

Content-Description: Card for koen van hoof


-- 
	Dan Nelson
	dnelson@emsphone.com

Re: TERMCAP problem.

[Bart Schaefer]

On Jan 15,  9:46am, Dan Nelson wrote:
} Subject: Re: TERMCAP problem.
}
} In the last episode (Jan 15), koen van hoof said:
} > zsh V3.1.9 and termcap V1.3 on SunOS se9ws265 5.6 Generic_105181-03
} > sun4u sparc
[...]
} > it core dumps, because at a certain moment getenv("TERM")
} > returns 0 and this is fed into a strcmp.
} 
} getenv("TERM") should never return 0.  screen sets both TERM and
} TERMCAP on all my machines.

But zsh shouldn't dump core when TERM is not set, even so.

Koen, you're going to have to give us more details (if you can) about the
core dump.  As far as I can tell, zsh never feeds the result of getenv()
directly to strcmp().  $TERM is handled by params.c:termsetfn(), which
always sets the global char *term to the empty string when $TERM is NULL;
later comparisons on the terminal type always use *term, which should
never be NULL unless ztrdup("") failed (which would indicate a serious
memory allocation problem).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: TERMCAP problem.

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

Bart Schaefer wrote:

> On Jan 15,  9:46am, Dan Nelson wrote:
> } Subject: Re: TERMCAP problem.
> }
> } In the last episode (Jan 15), koen van hoof said:
> } > zsh V3.1.9 and termcap V1.3 on SunOS se9ws265 5.6 Generic_105181-03
> } > sun4u sparc
> [...]
> } > it core dumps, because at a certain moment getenv("TERM")
> } > returns 0 and this is fed into a strcmp.
> }
> } getenv("TERM") should never return 0.  screen sets both TERM and
> } TERMCAP on all my machines.
>
> But zsh shouldn't dump core when TERM is not set, even so.
>
> Koen, you're going to have to give us more details (if you can) about the
> core dump.  As far as I can tell, zsh never feeds the result of getenv()
> directly to strcmp().  $TERM is handled by params.c:termsetfn(), which
> always sets the global char *term to the empty string when $TERM is NULL;
> later comparisons on the terminal type always use *term, which should
> never be NULL unless ztrdup("") failed (which would indicate a serious
> memory allocation problem).
>

Bart,
Here is the backtrace.  If you want, I can also send you the core file.
#0  0xef5a4274 in strcmp () from /usr/lib/libc.so.1
#1  0x126c00 in tgetent (bp=0x0, name=0x15c2e8 "xterm") at termcap.c:469
#2  0x48608 in init_term () at init.c:478
#3  0x6f808 in termsetfn (pm=0x145e20, x=0x15c2e8 "xterm") at params.c:2763
#4  0x6c514 in setstrvalue (v=0xefffed28, val=0x15c2e8 "xterm") at params.c:1513

#5  0x6d7d0 in setsparam (s=0xeffffe45 "", val=0x15c2e8 "xterm") at
params.c:1810
#6  0x6767c in createparamtable () at params.c:515
#7  0x491d0 in setupvals () at init.c:715
#8  0x12158 in main (argc=1, argv=0xeffff4ac) at ./main.c:78

>
> --
> Bart Schaefer                                 Brass Lantern Enterprises
> http://www.well.com/user/barts              http://www.brasslantern.com
>
> Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net

--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

RE: TERMCAP problem.

[Andrej Borsenkow]

> Here is the backtrace.  If you want, I can also send you the core file.
> #0  0xef5a4274 in strcmp () from /usr/lib/libc.so.1
> #1  0x126c00 in tgetent (bp=0x0, name=0x15c2e8 "xterm") at termcap.c:469
> #2  0x48608 in init_term () at init.c:478
> #3  0x6f808 in termsetfn (pm=0x145e20, x=0x15c2e8 "xterm") at params.c:2763
> #4  0x6c514 in setstrvalue (v=0xefffed28, val=0x15c2e8 "xterm") at
> params.c:1513
>
> #5  0x6d7d0 in setsparam (s=0xeffffe45 "", val=0x15c2e8 "xterm") at
> params.c:1810
> #6  0x6767c in createparamtable () at params.c:515
> #7  0x491d0 in setupvals () at init.c:715
> #8  0x12158 in main (argc=1, argv=0xeffff4ac) at ./main.c:78
>

This strcmp() is in library function tgetent. Try to unset
TGETENT_ACCEPTS_NULL, recompile and try again. It is possible that your OS
actually needs preallocated buffer.

One more possibilty is, that screen creates too long termcap entry. IIRC I've
seen something similar. How long is new termcap entry? I think, common limit
is 1024.

-andrej

Re: TERMCAP problem.

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

Andrej Borsenkow wrote:

>
> This strcmp() is in library function tgetent. Try to unset
> TGETENT_ACCEPTS_NULL, recompile and try again. It is possible that your OS
> actually needs preallocated buffer.
>
> One more possibilty is, that screen creates too long termcap entry. IIRC I've
> seen something similar. How long is new termcap entry? I think, common limit
> is 1024.
>
> -andrej

I've unset TGETENT_ACCEPTS_NULL.

$ export TERMCAP=abc
$ ./zhs
zsh: 26119 segmentation fault (core dumped)  ./zsh
$ ddd ./zsh core

And the backtrace is
#0  0xef5a4274 in strcmp () from /usr/lib/libc.so.1
#1  0x126c04 in tgetent (bp=0x14d018 "", name=0x15cae8 "xterm") at termcap.c:469

#2  0x4860c in init_term () at init.c:480
#3  0x6f80c in termsetfn (pm=0x145e20, x=0x15cae8 "xterm") at params.c:2763
#4  0x6c518 in setstrvalue (v=0xefffed38, val=0x15cae8 "xterm") at params.c:1513

#5  0x6d7d4 in setsparam (s=0xeffffe51 "", val=0x15cae8 "xterm") at
params.c:1810
#6  0x67680 in createparamtable () at params.c:515
#7  0x491d4 in setupvals () at init.c:715
#8  0x12158 in main (argc=1, argv=0xeffff4bc) at ./main.c:78

--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

Re: TERMCAP problem.

[Peter Stephenson]

> I've unset TGETENT_ACCEPTS_NULL.
> 
> $ export TERMCAP=abc
> $ ./zhs
> zsh: 26119 segmentation fault (core dumped)  ./zsh
> $ ddd ./zsh core
> 
> And the backtrace is
> #0  0xef5a4274 in strcmp () from /usr/lib/libc.so.1
> #1  0x126c04 in tgetent (bp=0x14d018 "", name=0x15cae8 "xterm") at termcap.c:
> 469
...

The next thing to try is Andrej's other point: increase the declared size
of termbuf until it doesn't crash any more (or increase it to 65536 and
start halving it).  If that works, we'll just have to add a few kb to the
shell to make sure (or use curses).

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: TERMCAP problem.

[Andrej Borsenkow]

>
>
> > I've unset TGETENT_ACCEPTS_NULL.
> >
> > $ export TERMCAP=abc
> > $ ./zhs
> > zsh: 26119 segmentation fault (core dumped)  ./zsh
> > $ ddd ./zsh core
> >
> > And the backtrace is
> > #0  0xef5a4274 in strcmp () from /usr/lib/libc.so.1
> > #1  0x126c04 in tgetent (bp=0x14d018 "", name=0x15cae8 "xterm")
> at termcap.c:
> > 469
> ...
>
> The next thing to try is Andrej's other point: increase the declared size
> of termbuf until it doesn't crash any more (or increase it to 65536 and
> start halving it).  If that works, we'll just have to add a few kb to the
> shell to make sure (or use curses).
>

One more possibility is that your termcap entry is corrupted (or your system
does not like something in termcap built by screen). I am not sure if
TERMCAP=abc is valid termcap entry anyway.

-andrej

Re: TERMCAP problem.

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Andrej Borsenkow wrote:

>
>
> One more possibility is that your termcap entry is corrupted (or your system
> does not like something in termcap built by screen). I am not sure if
> TERMCAP=abc is valid termcap entry anyway.
>
> -andrej

TERMCAP=abc is probably not a valid termcap, but should this cause a core dump ?

What value for TERMCAP should work, besides the name of a termcap file ?
Anyhow, if I step through the code in tgetent (termcap.c:415), it only tests
whether TERMCAP is set, and whether it does start witch a '/' (in which case it
is considered a file).


--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

RE: TERMCAP problem.

[Andrej Borsenkow]

>
> TERMCAP=abc is probably not a valid termcap, but should this cause
> a core dump ?
>

How do I know? I have not written this tgetent :-)

> What value for TERMCAP should work, besides the name of a termcap file ?
> Anyhow, if I step through the code in tgetent (termcap.c:415), it only tests
> whether TERMCAP is set, and whether it does start witch a '/' (in
> which case it
> is considered a file).
>

You refer to some file outside of zsh. No idea. I repeat - crash is inside of
tgetent; tgetent itself gets valid parameters. What happens thereafter is
outside of zsh control. O.K., one more possibility - clash between memory
allocation routines used in Zsh and your version of termcap.

What are zsh compile options? Do you compile with --enable-zsh-mem? What is
termcap 1.3 - does it come with SunOS? Try to recompile with standard OS
libraries and see if it helps.

-andrej

Re: TERMCAP problem.

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

Andrej Borsenkow wrote:

> >
> > TERMCAP=abc is probably not a valid termcap, but should this cause
> > a core dump ?
> >
>
> How do I know? I have not written this tgetent :-)
>
> > What value for TERMCAP should work, besides the name of a termcap file ?
> > Anyhow, if I step through the code in tgetent (termcap.c:415), it only tests
> > whether TERMCAP is set, and whether it does start witch a '/' (in
> > which case it
> > is considered a file).
> >
>
> You refer to some file outside of zsh. No idea. I repeat - crash is inside of
> tgetent; tgetent itself gets valid parameters. What happens thereafter is
> outside of zsh control. O.K., one more possibility - clash between memory
> allocation routines used in Zsh and your version of termcap.
>
> What are zsh compile options? Do you compile with --enable-zsh-mem? What is
> termcap 1.3 - does it come with SunOS? Try to recompile with standard OS
> libraries and see if it helps.
>
> -andrej

I checked previous versions of zsh, and version 3.1.2 did not have the problem.
In this version, all environment variables are first copied.
I checked "ChangeLog" and I found a change for 3.1.2 (hzoli, 3293) that explains
my problem.
Is this change still in in later releases ??

--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

Re: TERMCAP problem.

[Peter Stephenson]

> I checked previous versions of zsh, and version 3.1.2 did not have the proble
> m.
> In this version, all environment variables are first copied.
> I checked "ChangeLog" and I found a change for 3.1.2 (hzoli, 3293) that expla
> ins
> my problem.
> Is this change still in in later releases ??

It's changed since then.  If you have HAVE_PUTENV defined in config.h, try
undefining it for something a bit more like (but not identical to) the old
behaviour to see if that makes a difference.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: TERMCAP problem.

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Peter Stephenson wrote:

> > I checked previous versions of zsh, and version 3.1.2 did not have the proble
> > m.
> > In this version, all environment variables are first copied.
> > I checked "ChangeLog" and I found a change for 3.1.2 (hzoli, 3293) that expla
> > ins
> > my problem.
> > Is this change still in in later releases ??
>
> It's changed since then.  If you have HAVE_PUTENV defined in config.h, try
> undefining it for something a bit more like (but not identical to) the old
> behaviour to see if that makes a difference.
>
> --
> Peter Stephenson <pws@csr.com>                  Software Engineer
> Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
> Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

HAVE_PUTENV does not appear in any file.

--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

RE: TERMCAP problem.

[Andrej Borsenkow]

>
> It's changed since then.  If you have HAVE_PUTENV defined in config.h, try
> undefining it for something a bit more like (but not identical to) the old
> behaviour to see if that makes a difference.
>

I believe, I know what happens. When zsh creates parameters from environment,
it splits env string in-place; when tgetent is called (from init_term from
termsetfn), envronment string for TERM looks like

TERM\0xterm

Obviously, tgetent (or some functions called from it) does not like this. But
it was there for at least half an year already. I am not sure, but I think, it
was there before my patch as well.

I'll send a patch later, hopefully today.

-andrej

Some general problems with exporting cariables (Was: TERMCAP problem. )

[Andrej Borsenkow]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

>
>
> >
> > It's changed since then.  If you have HAVE_PUTENV defined in config.h, try
> > undefining it for something a bit more like (but not identical to) the old
> > behaviour to see if that makes a difference.
> >
>
> I believe, I know what happens. When zsh creates parameters from
> environment,
> it splits env string in-place;

Well, it turned out to be not directly related.  What actually happens is,
when zsh initially (in creatparamtable) gets env string for predefined colon
array it finally calls colnarrsetfn that unconditionally calls arrfixenv().
This one does not even check if variable is exported but simply tries to
replace environment string  with replenv() that tries to free previous
environment string ... that resides somewhere in global memory.

After we looped over env's all is clean again - every env string was allocated
by Zsh. But the above simply happens too early.

Ironically, when Zsh did not copy original env strings it appeared to work
(but who knows, what memory corruption could it cause). But when I wrote a
patch to copy original string, zsh started to crash.

I do not know, if it was my fault or was there before. I probably have not
changed usage of replenv() bit may have changed it's semantic. Anyway, as is
stands now, there seems to be no point in having it at all - either variable
is exported and has PM_EXPORTED set or it is not exported and does not have
this flag. If it is not true, something is seriously broken anyway. So, this
patch removes all replenv() usage with checking for PM_EXPORTED and addenv().
I still removed env string in-place modification just in case.

Koen, could you test if it helps? It appears to work here, but so did
unmodified Zsh as well. I appreciate, if anybody could review memory
allocation usage here - I still do not grok completely Zsh memory usage.

The patch is against current CVS.

-andrej

[-- Attachment #2: zsh.replenv.diff --]
[-- Type: application/octet-stream, Size: 3840 bytes --]

Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.30
diff -u -r1.30 params.c
--- Src/params.c	2001/01/16 13:44:20	1.30
+++ Src/params.c	2001/01/17 18:34:13
@@ -446,6 +446,32 @@
 	return NULL;
 }
 
+/*
+ * Split environment string into (name, vlaue) pair.
+ * this is used to avoid in-place editing of environment table
+ * that results in core dump on some systems
+ */
+
+static int
+split_env_string(char *env, char **name, char **value)
+{
+    char *str, *tenv;
+
+    if (!env || !name || !value)
+	return 0;
+
+    tenv = strcpy(zhalloc(strlen(env) + 1), env);
+    for (str = tenv; *str && *str != '='; str++)
+	;
+    if (str != tenv && *str == '=') {
+	*str = '\0';
+	*name = tenv;
+	*value = str + 1;
+	return 1;
+    } else
+	return 0;
+}
+    
 /* Set up parameter hash table.  This will add predefined  *
  * parameter entries as well as setting up parameter table *
  * entries for environment variables we inherit.           */
@@ -460,7 +486,7 @@
     int  envsize;
 #endif
     char **envp, **envp2, **sigptr, **t;
-    char buf[50], *str, *iname, *hostnam;
+    char buf[50], *str, *iname, *ivalue, *hostnam;
     int  oae = opts[ALLEXPORT];
 #ifdef HAVE_UNAME
     struct utsname unamebuf;
@@ -513,20 +539,18 @@
     environ = new_environ;
 #endif
 
+    /* Use heap allocation to avoid many small alloc/free calls */
+    pushheap();
+
     /* Now incorporate environment variables we are inheriting *
      * into the parameter hash table. Copy them into dynamic   *
      * memory so that we can free them if needed               */
     for (envp = envp2 = environ; *envp2; envp2++) {
-	for (str = *envp2; *str && *str != '='; str++);
-	if (*str == '=') {
-	    iname = NULL;
-	    *str = '\0';
-	    if (!idigit(**envp2) && isident(*envp2) && !strchr(*envp2, '[')) {
-		iname = *envp2;
+	if (split_env_string(*envp2, &iname, &ivalue)) {
+	    if (!idigit(*iname) && isident(iname) && !strchr(iname, '[')) {
 		if ((!(pm = (Param) paramtab->getnode(paramtab, iname)) ||
 		     !(pm->flags & PM_DONTIMPORT || pm->flags & PM_EXPORTED)) &&
-		    (pm = setsparam(iname, metafy(str + 1, -1, META_DUP)))) {
-		    *str = '=';
+		    (pm = setsparam(iname, metafy(ivalue, -1, META_DUP)))) {
 		    pm->flags |= PM_EXPORTED;
 		    if (pm->flags & PM_SPECIAL)
 			pm->env = mkenvstr (pm->nam,
@@ -536,9 +560,9 @@
 		    *envp++ = pm->env;
 		}
 	    }
-	    *str = '=';
 	}
     }
+    popheap();
     *envp = '\0';
     opts[ALLEXPORT] = oae;
 
@@ -1503,12 +1527,16 @@
 			pm->flags, NULL);
     else
 	val = pm->gets.cfn(pm);
+#if 0  /* looks like replenv is evil and should be removed */
     if (pm->env)
 	pm->env = replenv(pm->nam, val, pm->flags);
     else {
+#endif
 	pm->flags |= PM_EXPORTED;
 	pm->env = addenv(pm->nam, val, pm->flags);
+#if 0
     }
+#endif
 }
 
 /**/
@@ -2867,20 +2895,31 @@
     char *u;
     Param pm;
 
+    if (t == path)
+	cmdnamtab->emptytable(cmdnamtab);
+
     pm = (Param) paramtab->getnode(paramtab, s);
+    
     /*
+     * Do not "fix" parameters that were not exported
+     */
+
+    if (!(pm->flags & PM_EXPORTED) && !isset(ALLEXPORT))
+	return;
+
+    /*
      * Only one level of a parameter can be exported.  Unless
      * ALLEXPORT is set, this must be global.
      */
-    if (t == path)
-	cmdnamtab->emptytable(cmdnamtab);
     if (pm->flags & PM_HASHELEM)
 	return;
     u = t ? zjoin(t, ':', 1) : "";
+#if 0 /* attempt to get rid of evil replenv */
     if (findenv(s, 0)) {
 	pm->env = replenv(s, u, pm->flags);
 	return;
     }
+#endif
     if (isset(ALLEXPORT))
 	pm->flags |= PM_EXPORTED;
     if (pm->flags & PM_EXPORTED)

Re: Some general problems with exporting cariables (Was: TERMCAP problem. )

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Andrej Borsenkow wrote:

>
> Koen, could you test if it helps? It appears to work here, but so did
> unmodified Zsh as well. I appreciate, if anybody could review memory
> allocation usage here - I still do not grok completely Zsh memory usage.
>
> The patch is against current CVS.
>
> -andrej
>
>   --------------------------------------------------------------------------------
>                        Name: zsh.replenv.diff
>    zsh.replenv.diff    Type: unspecified type (application/octet-stream)
>                    Encoding: quoted-printable

I made a new executable from the current CVS, and even without the patch it did not
crash anymore.
For some reason, it how uses '-lcurses' instead of '-ltermcap'.

I did some tests with the debugger.
The crash happened because getenv("TERM") returned 0 during the call to tgetent from
the termcap library.
Whithout the patch, getenv("TERM") still returns 0, but now tgetent from libcursus.a
is used.
With the patch, getenv("TERM") returns "dumb" before tgetent is called, so I guess it
will also be fine for tgetent from the termcap library

Andrey,
thank you very much for your time and effort.

--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

RE: Some general problems with exporting cariables (Was: TERMCAP problem. )

[Andrej Borsenkow]

>
> I made a new executable from the current CVS, and even without the
> patch it did not
> crash anymore.

That is exactly what I was afraid of :-)

> For some reason, it how uses '-lcurses' instead of '-ltermcap'.
>

Yes, it is here but I have no idea what was the reason behind:

        * 12239: Fr. Br. George (George V Kouryachy), adapted:
        configure.in: prefer curses to termcap on solaris.

You may look in zsh-workes archive.

> I did some tests with the debugger.
> The crash happened because getenv("TERM") returned 0 during the
> call to tgetent from
> the termcap library.

Well, I am surpsised that it worked at all then, screen or no screen. May be,
the lack of `=' confused getenv.

> Whithout the patch, getenv("TERM") still returns 0, but now tgetent
> from libcursus.a
> is used.
> With the patch, getenv("TERM") returns "dumb" before tgetent is
> called, so I guess it
> will also be fine for tgetent from the termcap library

What do you mean "before""? Zsh itself never calls getenv("TERM").

Anyway, if this -lcurses is terminfo-based, you loose TERMCAP hack that screen
is using (unless newer screen version can cope with TERMINFO as well). I was
about to suggest adding LIBS=-ltermcap, but realised, that zsh is usiing
AC_CHECK_LIB. This macro stinks and should never be used - it does not check,
if function is already available, but blindly adds lib(s) even if not needed.

To all developers - shuld not we better consistenly use AC_SEARCH_LIBS
instead? This has major advantage - it checks first, if function is already
available, so you can easily override library list.

Koen, you can look in configure for a

case "$host_os" in
  aix*|hpux10.*|hpux11.*|solaris*)
      termcap_curses_order="curses ncurses termcap" ;;
  *)             termcap_curses_order="termcap curses ncurses" ;;
esac

remove solaris, and reconfigure zsh (probably, make distclean first). It
should give you old behaviour. Then we see if patch really helps :-)))

I'll change configure to use AC_SERCH_LIBS instead to be able to override
library selection.

-andrej

Re: Some general problems with exporting cariables (Was: TERMCAP problem. )

[koen van hoof]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Andrej Borsenkow wrote:

>
>
> > Whithout the patch, getenv("TERM") still returns 0, but now tgetent
> > from libcursus.a
> > is used.
> > With the patch, getenv("TERM") returns "dumb" before tgetent is
> > called, so I guess it
> > will also be fine for tgetent from the termcap library
>
> What do you mean "before""? Zsh itself never calls getenv("TERM").

I did it manualy from within the debugger

>
> Koen, you can look in configure for a
>
> case "$host_os" in
>   aix*|hpux10.*|hpux11.*|solaris*)
>       termcap_curses_order="curses ncurses termcap" ;;
>   *)             termcap_curses_order="termcap curses ncurses" ;;
> esac
>
> remove solaris, and reconfigure zsh (probably, make distclean first). It
> should give you old behaviour. Then we see if patch really helps :-)))
>
> I'll change configure to use AC_SERCH_LIBS instead to be able to override
> library selection.
>
> -andrej

It now uses termcap again.
Zsh without the patch crashes within screen.
After applying the patch, it works fine. !!!!

-Koen

--
==========================================================
Koen Van Hoof    koen.van_hoof@alcatel.be   32 3 451 60 31
==========================================================



[-- Attachment #2: Card for koen van hoof --]
[-- Type: text/x-vcard, Size: 156 bytes --]

begin:vcard 
n:Van Hoof;Koen
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:koen.van_hoof@alcatel.be
x-mozilla-cpt:;0
fn:Koen Van Hoof
end:vcard

RE: Some general problems with exporting cariables (Was: TERMCAP problem. )

[Andrej Borsenkow]

> >
> > I'll change configure to use AC_SERCH_LIBS instead to be able to override
> > library selection.

> It now uses termcap again.
> Zsh without the patch crashes within screen.
> After applying the patch, it works fine. !!!!
> 

O.K. I've committed both (I did cosmetic modification of  13370). 

It should now be possible to select termcap by 

configure --enable-libs=-ltermcap

(LIBS=-ltermcap should work as well, but is not preserved by config.status).

-andrej