* TERMCAP problem. @ 2001-01-15 10:14 koen van hoof 2001-01-15 15:46 ` Dan Nelson 0 siblings, 1 reply; 19+ messages in thread From: koen van hoof @ 2001-01-15 10:14 UTC (permalink / raw) To: zsh-workers [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-15 10:14 TERMCAP problem koen van hoof @ 2001-01-15 15:46 ` Dan Nelson 2001-01-15 17:23 ` Bart Schaefer 0 siblings, 1 reply; 19+ messages in thread From: Dan Nelson @ 2001-01-15 15:46 UTC (permalink / raw) To: koen van hoof; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-15 15:46 ` Dan Nelson @ 2001-01-15 17:23 ` Bart Schaefer 2001-01-16 8:30 ` koen van hoof 0 siblings, 1 reply; 19+ messages in thread From: Bart Schaefer @ 2001-01-15 17:23 UTC (permalink / raw) To: koen van hoof; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-15 17:23 ` Bart Schaefer @ 2001-01-16 8:30 ` koen van hoof 2001-01-16 8:52 ` Andrej Borsenkow 0 siblings, 1 reply; 19+ messages in thread From: koen van hoof @ 2001-01-16 8:30 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: TERMCAP problem. 2001-01-16 8:30 ` koen van hoof @ 2001-01-16 8:52 ` Andrej Borsenkow 2001-01-16 10:42 ` koen van hoof 0 siblings, 1 reply; 19+ messages in thread From: Andrej Borsenkow @ 2001-01-16 8:52 UTC (permalink / raw) To: koen.van_hoof; +Cc: zsh-workers > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-16 8:52 ` Andrej Borsenkow @ 2001-01-16 10:42 ` koen van hoof 2001-01-16 10:54 ` Peter Stephenson 0 siblings, 1 reply; 19+ messages in thread From: koen van hoof @ 2001-01-16 10:42 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: zsh-workers [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-16 10:42 ` koen van hoof @ 2001-01-16 10:54 ` Peter Stephenson 2001-01-16 11:19 ` Andrej Borsenkow 0 siblings, 1 reply; 19+ messages in thread From: Peter Stephenson @ 2001-01-16 10:54 UTC (permalink / raw) To: koen.van_hoof, Zsh hackers list > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: TERMCAP problem. 2001-01-16 10:54 ` Peter Stephenson @ 2001-01-16 11:19 ` Andrej Borsenkow 2001-01-16 11:56 ` koen van hoof 0 siblings, 1 reply; 19+ messages in thread From: Andrej Borsenkow @ 2001-01-16 11:19 UTC (permalink / raw) To: koen.van_hoof, Zsh hackers list > > > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-16 11:19 ` Andrej Borsenkow @ 2001-01-16 11:56 ` koen van hoof 2001-01-16 12:11 ` Andrej Borsenkow 0 siblings, 1 reply; 19+ messages in thread From: koen van hoof @ 2001-01-16 11:56 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: Zsh hackers list [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: TERMCAP problem. 2001-01-16 11:56 ` koen van hoof @ 2001-01-16 12:11 ` Andrej Borsenkow 2001-01-16 16:27 ` koen van hoof 0 siblings, 1 reply; 19+ messages in thread From: Andrej Borsenkow @ 2001-01-16 12:11 UTC (permalink / raw) To: koen.van_hoof; +Cc: Zsh hackers list > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-16 12:11 ` Andrej Borsenkow @ 2001-01-16 16:27 ` koen van hoof 2001-01-16 17:05 ` Peter Stephenson 0 siblings, 1 reply; 19+ messages in thread From: koen van hoof @ 2001-01-16 16:27 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: Zsh hackers list, zefram [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-16 16:27 ` koen van hoof @ 2001-01-16 17:05 ` Peter Stephenson 2001-01-17 7:46 ` koen van hoof 2001-01-17 7:53 ` Andrej Borsenkow 0 siblings, 2 replies; 19+ messages in thread From: Peter Stephenson @ 2001-01-16 17:05 UTC (permalink / raw) To: koen.van_hoof, Zsh hackers list > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TERMCAP problem. 2001-01-16 17:05 ` Peter Stephenson @ 2001-01-17 7:46 ` koen van hoof 2001-01-17 7:53 ` Andrej Borsenkow 1 sibling, 0 replies; 19+ messages in thread From: koen van hoof @ 2001-01-17 7:46 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: TERMCAP problem. 2001-01-16 17:05 ` Peter Stephenson 2001-01-17 7:46 ` koen van hoof @ 2001-01-17 7:53 ` Andrej Borsenkow 2001-01-17 18:41 ` Some general problems with exporting cariables (Was: TERMCAP problem. ) Andrej Borsenkow 1 sibling, 1 reply; 19+ messages in thread From: Andrej Borsenkow @ 2001-01-17 7:53 UTC (permalink / raw) To: koen.van_hoof, Zsh hackers list > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Some general problems with exporting cariables (Was: TERMCAP problem. ) 2001-01-17 7:53 ` Andrej Borsenkow @ 2001-01-17 18:41 ` Andrej Borsenkow 2001-01-18 12:34 ` koen van hoof 0 siblings, 1 reply; 19+ messages in thread From: Andrej Borsenkow @ 2001-01-17 18:41 UTC (permalink / raw) To: Zsh hackers list, koen.van_hoof [-- 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) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Some general problems with exporting cariables (Was: TERMCAP problem. ) 2001-01-17 18:41 ` Some general problems with exporting cariables (Was: TERMCAP problem. ) Andrej Borsenkow @ 2001-01-18 12:34 ` koen van hoof 2001-01-18 13:16 ` Andrej Borsenkow 0 siblings, 1 reply; 19+ messages in thread From: koen van hoof @ 2001-01-18 12:34 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: Zsh hackers list [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: Some general problems with exporting cariables (Was: TERMCAP problem. ) 2001-01-18 12:34 ` koen van hoof @ 2001-01-18 13:16 ` Andrej Borsenkow 2001-01-18 15:54 ` koen van hoof 0 siblings, 1 reply; 19+ messages in thread From: Andrej Borsenkow @ 2001-01-18 13:16 UTC (permalink / raw) To: koen.van_hoof; +Cc: Zsh hackers list > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Some general problems with exporting cariables (Was: TERMCAP problem. ) 2001-01-18 13:16 ` Andrej Borsenkow @ 2001-01-18 15:54 ` koen van hoof 2001-01-19 15:05 ` Andrej Borsenkow 0 siblings, 1 reply; 19+ messages in thread From: koen van hoof @ 2001-01-18 15:54 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: Zsh hackers list [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: Some general problems with exporting cariables (Was: TERMCAP problem. ) 2001-01-18 15:54 ` koen van hoof @ 2001-01-19 15:05 ` Andrej Borsenkow 0 siblings, 0 replies; 19+ messages in thread From: Andrej Borsenkow @ 2001-01-19 15:05 UTC (permalink / raw) To: koen.van_hoof; +Cc: Zsh hackers list > > > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2001-01-19 15:06 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-01-15 10:14 TERMCAP problem koen van hoof 2001-01-15 15:46 ` Dan Nelson 2001-01-15 17:23 ` Bart Schaefer 2001-01-16 8:30 ` koen van hoof 2001-01-16 8:52 ` Andrej Borsenkow 2001-01-16 10:42 ` koen van hoof 2001-01-16 10:54 ` Peter Stephenson 2001-01-16 11:19 ` Andrej Borsenkow 2001-01-16 11:56 ` koen van hoof 2001-01-16 12:11 ` Andrej Borsenkow 2001-01-16 16:27 ` koen van hoof 2001-01-16 17:05 ` Peter Stephenson 2001-01-17 7:46 ` koen van hoof 2001-01-17 7:53 ` Andrej Borsenkow 2001-01-17 18:41 ` Some general problems with exporting cariables (Was: TERMCAP problem. ) Andrej Borsenkow 2001-01-18 12:34 ` koen van hoof 2001-01-18 13:16 ` Andrej Borsenkow 2001-01-18 15:54 ` koen van hoof 2001-01-19 15:05 ` Andrej Borsenkow
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).