* Bug Report: Env Vars and shell functions @ 1996-07-08 3:49 Peter Bray 1996-07-08 8:58 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Peter Bray @ 1996-07-08 3:49 UTC (permalink / raw) To: zsh-workers; +Cc: Peter Bray Note: I'm not a member of any of the mailing lists Greetings, Can others reproduce this bug in zsh-3.0-pre2, where a command line environment variable is ignored in other functions called by the original functions. Very trivial double function calls seem to work fine but some where the code in "allLogicalHosts" seems to upset the second function call. This code has been stripped a bit but not completely, those wish to construct a similar directory structure, can or alternatively you can comment out the eval line and use the explicit variable set on the line below that in "allLogicalHosts". History: Early beta version of zsh-2.6 ( < beta-9 ?? ) worked but it was broken somewhere and fixed was introduced in beta-1X according to the changelogs, unfortunately I didn't have the time to test all the new beta versions Regards, Peter ------------------------------------------------------------------------------ Peter Bray: Intelligent Network Development Phone : (02) 395 3958 Network Technology Group - Telstra Fax : (02) 395 3225 Street : Lvl 9, Telecom Plaza, 320 Pitt St, Sydney Email : Mail : Locked Bag 6581, GPO Sydney, NSW, 1100 pbray@ind.tansu.com.au ------------------------------------------------------------------------------ Environment : SPARC Solaris 2.5 & 2.5.1 - zsh 3.0pre2 [pbray@swan] /tmp > du -k /tmp/tsaf 4 /tmp/tsaf/a@b/current 8 /tmp/tsaf/a@b 4 /tmp/tsaf/xxx@yyy/current 8 /tmp/tsaf/xxx@yyy 20 /tmp/tsaf [pbray@swan] /tmp > source /tmp/zshenv TSAF_VERBOSE --> echo Arguments --> a@b current TSAF_VERBOSE --> echo Arguments --> xxx@yyy current ############### ^^^^ why isn't this a ":" [pbray@swan] /tmp > cat /tmp/zshenv # # Example Directory Structure # ${prefix}/a@b/current # ${prefix}/a@b/backup # ${prefix}/xxx@yyy/current # ${prefix}/xxx@yyy/backup # setLogicalHost() { TSAF_VERBOSE=${TSAF_VERBOSE:-echo} echo "TSAF_VERBOSE --> ${TSAF_VERBOSE} Arguments --> $*" } allLogicalHosts() { prefix=/tmp/tsaf version=${1:-current} ## Comment out one off the two lines below eval 'hostList=`echo ${prefix}/*@*`' 2>/dev/null #hostList="a@b c@d" for logicalHost in `echo ${hostList}` do setLogicalHost `basename $logicalHost` ${version} done } TSAF_VERBOSE=: allLogicalHosts ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-08 3:49 Bug Report: Env Vars and shell functions Peter Bray @ 1996-07-08 8:58 ` Bart Schaefer 1996-07-08 12:49 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 1996-07-08 8:58 UTC (permalink / raw) To: Peter Bray, zsh-workers On Jul 8, 1:49pm, Peter Bray wrote: } Subject: Bug Report: Env Vars and shell functions } } Can others reproduce this bug in zsh-3.0-pre2, where a command } line environment variable is ignored in other functions called by the } original functions. The local environment seems to get lost on the second and succeeding passes around the 'for' loop. zagzig[52] bar() { echo $1 $BAR } zagzig[53] foo() { bar } zagzig[54] BAR=foo foo foo zagzig[55] foo() { for x in 1 2 3 ; do bar $x ; done } zagzig[56] foo 1 2 3 zagzig[57] BAR=foo foo 1 foo 2 3 I didn't try other looping constructs. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-08 8:58 ` Bart Schaefer @ 1996-07-08 12:49 ` Peter Stephenson 1996-07-10 2:33 ` Zoltan Hidvegi 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 1996-07-08 12:49 UTC (permalink / raw) To: Zsh hackers list schaefer@candle.brasslantern.com wrote: > On Jul 8, 1:49pm, Peter Bray wrote: > } Subject: Bug Report: Env Vars and shell functions > } > } Can others reproduce this bug in zsh-3.0-pre2, where a command > } line environment variable is ignored in other functions called by the > } original functions. > > The local environment seems to get lost on the second and succeeding > passes around the 'for' loop. > > zagzig[52] bar() { echo $1 $BAR } > zagzig[53] foo() { bar } > zagzig[54] BAR=foo foo > foo > zagzig[55] foo() { for x in 1 2 3 ; do bar $x ; done } > zagzig[56] foo > 1 > 2 > 3 > zagzig[57] BAR=foo foo > 1 foo > 2 > 3 The culprit is the save_params()/restore_params() mechanism called from execcmd() to handle temporary settings during builtins, which uses static variables. Only the original author of that can say why it wasn't scoped within execcmd() and therefore if I'm missing something with the following patch. I honestly can't see any problem: I've made sure everything gets restored, including the only abnormal return. However, that can hardly have been the problem being worked around, since in fact the same abnormal return would before have potentially left dreck hanging on removelist/restorelist. I can't see any new scope for leakage. *** Src/exec.c.savpar Mon Jul 8 09:29:41 1996 --- Src/exec.c Mon Jul 8 14:37:10 1996 *************** *** 1561,1571 **** lastval = (func[type - CURSH]) (cmd); } else if (is_builtin || is_shfunc) { /* builtin or shell function */ if (!forked && !assign) { PERMALLOC { ! save_params(cmd); } LASTALLOC; } --- 1561,1572 ---- lastval = (func[type - CURSH]) (cmd); } else if (is_builtin || is_shfunc) { + LinkList restorelist = 0, removelist = 0; /* builtin or shell function */ if (!forked && !assign) { PERMALLOC { ! save_params(cmd, &restorelist, &removelist); } LASTALLOC; } *************** *** 1575,1580 **** --- 1576,1582 ---- */ addvars(cmd->vars, is_shfunc); if (errflag) { + restore_params(restorelist, removelist); lastval = 1; return; } *************** *** 1632,1639 **** exit(lastval); } ! if (!forked && !assign) ! restore_params(); } else { if (cmd->flags & CFLAG_EXEC) { --- 1634,1640 ---- exit(lastval); } ! restore_params(restorelist, removelist); } else { if (cmd->flags & CFLAG_EXEC) { *************** *** 1672,1693 **** fixfds(save); } - /* Link list used to save parameters during * - * execution of shfunc or builtin. */ - static LinkList restorelist; - static LinkList removelist; - - /* Setup the link lists use to save parameters * - * for shfuncs or builtins. */ - - /**/ - void - init_save_params(void) - { - restorelist = newlinklist(); - removelist = newlinklist(); - } - /* Arrange to have variables restored. * * As yet special parameters won't work, nor will * * parameter names that need substituting. * --- 1673,1678 ---- *************** *** 1695,1716 **** /**/ void ! save_params(Cmd cmd) { Param pm; LinkNode node; char *s; for (node = firstnode(cmd->vars); node; incnode(node)) { s = ((Varasg) getdata(node))->name; if ((pm = (Param) paramtab->getnode(paramtab, s))) { if (!(pm->flags & PM_SPECIAL)) { paramtab->removenode(paramtab, s); ! addlinknode(removelist, s); ! addlinknode(restorelist, pm); } } else { ! addlinknode(removelist, s); } } } --- 1680,1704 ---- /**/ void ! save_params(Cmd cmd, LinkList *restore_p, LinkList *remove_p) { Param pm; LinkNode node; char *s; + *restore_p = newlinklist(); + *remove_p = newlinklist(); + for (node = firstnode(cmd->vars); node; incnode(node)) { s = ((Varasg) getdata(node))->name; if ((pm = (Param) paramtab->getnode(paramtab, s))) { if (!(pm->flags & PM_SPECIAL)) { paramtab->removenode(paramtab, s); ! addlinknode(*remove_p, s); ! addlinknode(*restore_p, pm); } } else { ! addlinknode(*remove_p, s); } } } *************** *** 1719,1736 **** /**/ void ! restore_params(void) { Param pm; char *s; ! /* remove temporary parameters */ ! while ((s = (char *) getlinknode(removelist))) ! unsetparam(s); ! ! /* restore saved parameters */ ! while ((pm = (Param) getlinknode(restorelist))) ! paramtab->addnode(paramtab, pm->nam, pm); } /* restore fds after redirecting a builtin */ --- 1707,1730 ---- /**/ void ! restore_params(LinkList restorelist, LinkList removelist) { Param pm; char *s; ! if (removelist) { ! /* remove temporary parameters */ ! while ((s = (char *) getlinknode(removelist))) ! unsetparam(s); ! freelinklist(removelist, 0); ! } ! ! if (restorelist) { ! /* restore saved parameters */ ! while ((pm = (Param) getlinknode(restorelist))) ! paramtab->addnode(paramtab, pm->nam, pm); ! freelinklist(restorelist, 0); ! } } /* restore fds after redirecting a builtin */ *** Src/init.c.savpar Mon Jul 8 09:30:24 1996 --- Src/init.c Mon Jul 8 14:30:47 1996 *************** *** 597,603 **** initkeybindings(); /* initialize key bindings */ compctlsetup(); - init_save_params(); /* init saving params during shfunc or builtin */ #ifdef HAVE_GETRLIMIT for (i = 0; i != RLIM_NLIMITS; i++) --- 597,602 ---- -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77330 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-08 12:49 ` Peter Stephenson @ 1996-07-10 2:33 ` Zoltan Hidvegi 1996-07-10 12:19 ` Vinnie Shelton 0 siblings, 1 reply; 12+ messages in thread From: Zoltan Hidvegi @ 1996-07-10 2:33 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers There is still a bug here: % bug () { : } % export FOO=foo % FOO=bar bug % printenv FOO bar The patch below hepefully fixes that. Zoltan *** Src/exec.c 1996/07/10 02:15:42 2.55 --- Src/exec.c 1996/07/10 02:15:50 *************** *** 1696,1701 **** --- 1696,1706 ---- paramtab->removenode(paramtab, s); addlinknode(*remove_p, s); addlinknode(*restore_p, pm); + if ((pm->flags & PM_EXPORTED) && pm->env) { + delenv(pm->env); + zsfree(pm->env); + pm->env = NULL; + } } } else { addlinknode(*remove_p, s); *************** *** 1721,1728 **** if (restorelist) { /* restore saved parameters */ ! while ((pm = (Param) getlinknode(restorelist))) paramtab->addnode(paramtab, pm->nam, pm); freelinklist(restorelist, 0); } } --- 1726,1736 ---- if (restorelist) { /* restore saved parameters */ ! while ((pm = (Param) getlinknode(restorelist))) { paramtab->addnode(paramtab, pm->nam, pm); + if (pm->flags & PM_EXPORTED) + pm->env = addenv(pm->nam, getsparam(pm->nam)); + } freelinklist(restorelist, 0); } } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-10 2:33 ` Zoltan Hidvegi @ 1996-07-10 12:19 ` Vinnie Shelton 1996-07-10 13:45 ` Zoltan Hidvegi 0 siblings, 1 reply; 12+ messages in thread From: Vinnie Shelton @ 1996-07-10 12:19 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: Peter Stephenson, zsh-workers There's still a bug here; with 3.0-pre2 and only Peter's patch from article 1573 and Zoltan's fix from article 1596, here's what happens: : zsh-3.0-pre2/Solaris Wed 10 8:08; env - /pd/osbin/zsh -f spacely% echo $ZSH_VERSION 3.0-pre2 spacely% function foo { > echo "Function foo; FOO = $FOO" > ./x > } spacely% cat ./x #!/pd/osbin/zsh -f print "This is $0; FOO = $FOO" spacely% foo Function foo; FOO = This is ./x; FOO = spacely% FOO=BAR foo Function foo; FOO = BAR This is ./x; FOO = BAR # Okay so far, but... spacely% foo Function foo; FOO = This is ./x; FOO = BAR FOO should be unset during the last running of ./x. --vin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-10 12:19 ` Vinnie Shelton @ 1996-07-10 13:45 ` Zoltan Hidvegi 1996-07-11 22:11 ` Anthony Heading 0 siblings, 1 reply; 12+ messages in thread From: Zoltan Hidvegi @ 1996-07-10 13:45 UTC (permalink / raw) To: acs; +Cc: pws, zsh-workers > There's still a bug here; with 3.0-pre2 and only Peter's patch from > article 1573 and Zoltan's fix from article 1596, here's what happens: > > : zsh-3.0-pre2/Solaris Wed 10 8:08; env - /pd/osbin/zsh -f > spacely% echo $ZSH_VERSION > 3.0-pre2 > spacely% function foo { > > echo "Function foo; FOO = $FOO" > > ./x > > } > spacely% cat ./x > #!/pd/osbin/zsh -f > > print "This is $0; FOO = $FOO" > spacely% foo > Function foo; FOO = > This is ./x; FOO = > spacely% FOO=BAR foo > Function foo; FOO = BAR > This is ./x; FOO = BAR > > # Okay so far, but... > > spacely% foo > Function foo; FOO = > This is ./x; FOO = BAR > > FOO should be unset during the last running of ./x. The patch below should fix that. It also removes the first hunk of my previous patch since it is not necessary. Zoltan *** Src/exec.c 1996/07/10 02:34:49 2.56 --- Src/exec.c 1996/07/10 13:32:33 *************** *** 1055,1060 **** --- 1055,1061 ---- if (v->type == PM_SCALAR && (empty(vl) || !nextnode(firstnode(vl)))) { Param pm; char *val; + int allexp; if (empty(vl)) val = ztrdup(""); *************** *** 1064,1074 **** } if (xtr) fprintf(stderr, "%s ", val); ! pm = setsparam(v->name, ztrdup(val)); if (errflag) return; - if (export && !(pm->flags & PM_EXPORTED)) - addenv(v->name, val); zsfree(val); continue; } --- 1065,1079 ---- } if (xtr) fprintf(stderr, "%s ", val); ! if (export) { ! allexp = opts[ALLEXPORT]; ! opts[ALLEXPORT] = 1; ! pm = setsparam(v->name, ztrdup(val)); ! opts[ALLEXPORT] = allexp; ! } else ! pm = setsparam(v->name, ztrdup(val)); if (errflag) return; zsfree(val); continue; } *************** *** 1696,1706 **** paramtab->removenode(paramtab, s); addlinknode(*remove_p, s); addlinknode(*restore_p, pm); - if ((pm->flags & PM_EXPORTED) && pm->env) { - delenv(pm->env); - zsfree(pm->env); - pm->env = NULL; - } } } else { addlinknode(*remove_p, s); --- 1701,1706 ---- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-10 13:45 ` Zoltan Hidvegi @ 1996-07-11 22:11 ` Anthony Heading 1996-07-12 12:17 ` Peter Stephenson 1996-07-12 15:27 ` Zoltan Hidvegi 0 siblings, 2 replies; 12+ messages in thread From: Anthony Heading @ 1996-07-11 22:11 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: acs, pws, zsh-workers Zoltan wrote: > The patch below should fix that. It also removes the first hunk of my > previous patch since it is not necessary. With 1573, 1596 and 1598 applied to pre-2, not that these are likely relevant, I get a segfault with the following sun4% zsh -c xyzzy hello zsh: 18399 segmentation fault zsh -c xyzzy where xyzzy is an autoloaded function containing #!/usr/local/bin/zsh . thing and `thing' is a file reading echo hello Traceback attached. None of the alloc_stackp related patches applied, since they seemed all to be cosmetic. On a related note, should the following not restore IFS? sun4% IFS=@ set a@b@c@d; echo $IFS @ And finally, why doesn't this work? sun4% local x=($(date)) zsh: not an identifier: 10 BST 1996) I think this stops one saying IFS=@ local x=($(blaa)) using local, or perhaps the even more vanilla typeset -t, as a way of making the change to x permanent but restoring IFS. Though maybe my whole notion was flawed -- I was trying to split a command output into lines, but the various expansions that happen after command substitution "corrupt" the data. Ah. Another core dump: sun4% $(grep[TAB][TAB] Program received signal SIGSEGV, Segmentation fault. 0x6ff8128c in _doprnt () #2 0x9afd0 in doexpandhist () at zle_tricky.c:3817 3817 DPUTS(useheap, "BUG: useheap in doexpandhist()"); Hmm. Time I went home. Cheers Anthony =========================================================== sun4% gdb zsh GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15.1 (sparc-sun-sunos4.1.3_U1), Copyright 1995 Free Software Foundation, Inc... (gdb) run -c xyzzy Starting program: /tmp_mnt/home/research/aheading/build/zsh-3.0-pre2/Src/zsh -c xyzzy hello Program received signal SIGSEGV, Segmentation fault. 0x6ff8128c in _doprnt () (gdb) where #0 0x6ff8128c in _doprnt () #1 0x6ff835c4 in fprintf () #2 0x3c04c in loop (toplevel=0) at init.c:131 #3 0x3e4fc in source (s=0xefffe9f0 "thing") at init.c:779 #4 0x16080 in bin_dot (name=0xbdc64 ".", argv=0xbdccc, ops=0xefffeea8 "", func=0) at builtin.c:4657 #5 0x2d10 in execbuiltin (args=0xbdc5c, bn=0xafc1c) at builtin.c:189 #6 0x22980 in execcmd (cmd=0xbdc3c, input=0, output=0, how=2, last1=2) at exec.c:1611 #7 0x1f0ec in execpline2 (pline=0xbdcac, how=2, input=0, output=0, last1=0) at exec.c:781 #8 0x1e600 in execpline (l=0xbdc98, how=2, last1=0) at exec.c:627 #9 0x1e0ec in execlist (list=0xbdc88, dont_change_job=1, exiting=0) at exec.c:508 #10 0x25878 in doshfunc (list=0xc0288, doshargs=0xbdbf8, flags=0, noreturnval=0) at exec.c:2422 #11 0x25464 in execshfunc (cmd=0xbdbd8, shf=0xc5520) at exec.c:2349 #12 0x22944 in execcmd (cmd=0xbdbd8, input=0, output=0, how=2, last1=1) at exec.c:1600 #13 0x1f0ec in execpline2 (pline=0xbdc1c, how=2, input=0, output=0, last1=1) at exec.c:781 #14 0x1e600 in execpline (l=0xbdbc4, how=2, last1=1) at exec.c:627 #15 0x1e0ec in execlist (list=0xbdc2c, dont_change_job=0, exiting=1) at exec.c:508 #16 0x1df50 in execstring (s=0xeffff916 "xyzzy", dont_change_job=0, exiting=1) at exec.c:466 #17 0x3e324 in init_misc () at init.c:738 #18 0x3bd5c in main (argc=3, argv=0xeffff844) at init.c:73 (gdb) frame 2 #2 0x3c04c in loop (toplevel=0) at init.c:131 131 DPUTS(alloc_stackp, "BUG: alloc_stackp != 0 in loop()"); (gdb) print alloc_stackp $1 = 1 =================================================== ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-11 22:11 ` Anthony Heading @ 1996-07-12 12:17 ` Peter Stephenson 1996-07-12 15:27 ` Zoltan Hidvegi 1 sibling, 0 replies; 12+ messages in thread From: Peter Stephenson @ 1996-07-12 12:17 UTC (permalink / raw) To: zsh-workers aheading@jpmorgan.com wrote: > On a related note, should the following not restore IFS? > > sun4% IFS=@ set a@b@c@d; echo $IFS > @ This is a very ancient, revered and traditional bug, handed down since time immemorial from the hand of pfalstad himself. Special parameters aren't restored after builtin constructs, unlike other parameters (at least, after Zoltan's recent patches). The problem is that there are numerous different ways for setting builtins, and to do this properly would mean save/restore functions for each. One hack (actually, that's unfair --- I've used more or less the same trick in a C++ parameter-reading class with templated virtual functions, relying only on the presence of insertors and extractors for the type in question, and it works vey nicely) that might work here with a lot of parameters (but not such as SECONDS, which would really need its own functions) is to retrieve the parameter as a string value with the function used with $VAR for printing, getstrvalue(), store that, then call the function that sets the parameter from a string supplied on the command line with VAR=..., setsparam(). This would do the trick reasonably simply for things like PATH and IFS. Probably care is needed, e.g. you can forget this for arrays and what do you do if someone tries it with $path or $cdpath? Any comments? Any implementations??? > And finally, why doesn't this work? > sun4% local x=($(date)) > zsh: not an identifier: 10 BST 1996) Do you mean, why can't you assign arrays from `local'? I don't see any prospect of doing it like that, since you would need special parsing of the stuff in parentheses, which is somewhat abhorrent for something that's supposed to look like an ordinary command; passing the argument as a single word gets you into problems of how to split it later --- and in the case shown, you still need special parsing to avoid getting the expansion local x=Fri Jul 12 14:12:47 MET 1996 with fully-paid-up spaces between the arguments, which is what is currently (and correctly) happening. (Csh does special parsing after `set', 'nuff said). It should, however, definitely be possible to do the equivalent of `set -A' with local or typeset, but it isn't. This is very nearly a bug. Actually, I don't quite understand that error message, since it suggests the last few words are passed as one, which isn't happening to me. -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77330 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-11 22:11 ` Anthony Heading 1996-07-12 12:17 ` Peter Stephenson @ 1996-07-12 15:27 ` Zoltan Hidvegi 1996-07-12 16:01 ` Anthony Heading 1996-07-12 17:18 ` Bart Schaefer 1 sibling, 2 replies; 12+ messages in thread From: Zoltan Hidvegi @ 1996-07-12 15:27 UTC (permalink / raw) To: Anthony Heading; +Cc: acs, pws, zsh-workers > I get a segfault with the following > > sun4% zsh -c xyzzy > hello > zsh: 18399 segmentation fault zsh -c xyzzy > > where xyzzy is an autoloaded function containing > > #!/usr/local/bin/zsh > . thing > > and `thing' is a file reading > > echo hello > > Traceback attached. None of the alloc_stackp related patches applied, since > they seemed all to be cosmetic. They were not really cosmetic. Had you applied these you would not have received this. These SEGV's are all caused by DPUTS, since it seems that you did not applied the patch which replaces X to Y in DPUTS in zsh.h line 1314. That was a silly typo I made before pre2 which means zsh crashes every time when DPUTS wants to print something (which makes it look much more serious). > On a related note, should the following not restore IFS? > > sun4% IFS=@ set a@b@c@d; echo $IFS > @ Here is what POSIX says: (2) Variable assignments specified with special built-in utilities shall remain in effect after the built-in completes; this shall not be the case with a regular built-in or other utility. And POSIX special builtins are . continue exit return trap : eval export set unset break exec readonly shift And it also says that shell functions should be handled similarily to special builtins (which means that recent patches from Peter and me make zsh less conformant). Zsh currently treats a builtin this way only if the BINF_MAGICEQUALS flag is set for the builtin. These builtins are: alias, declare, hash, integer, local, readonly and typeset. Of course zsh does not conforms to the POSIX rule and handling of special parameters in undoubtadly not the best but it also means that applications should not expect local variable assignments before special builtins since it may change in the future. Also note that command arguments are evaluated before variable assignments so the above example will never work. The other problem with that example is that field splitting is only done on the result of expansions so the explicitely given a@b@c@d is not split even if IFS is set correctly before set. In a POSIX shell the command builtin can be used to execute special builtins (in zsh it executes external command only). Note that command in not listed among the special builtins above which means that the special assignment behaviour can be prevented by prefixing a special builtin with the command builtin (I'm talking about POSIX and not about zsh). I'm writing these because these differences between zsh and POSIX are probably the most important ones. Other than that zsh is now mostly POSIX conformant (POSIX does not allow the MAGICEQUALS behaviour of the typeset family but all other shells (bash, ksh93 and pdksh) do that unles POSIXLY_CORRECT is defined). > Ah. Another core dump: > sun4% $(grep[TAB][TAB] > Program received signal SIGSEGV, Segmentation fault. > 0x6ff8128c in _doprnt () > #2 0x9afd0 in doexpandhist () at zle_tricky.c:3817 > 3817 DPUTS(useheap, "BUG: useheap in doexpandhist()"); That is already fixed some time ago. It was a misplaced goto label. Zoltan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-12 15:27 ` Zoltan Hidvegi @ 1996-07-12 16:01 ` Anthony Heading 1996-07-12 17:18 ` Bart Schaefer 1 sibling, 0 replies; 12+ messages in thread From: Anthony Heading @ 1996-07-12 16:01 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: zsh-workers > They were not really cosmetic. Had you applied these you would not have > received this. These SEGV's are all caused by DPUTS, since it seems that > you did not applied the patch which replaces X to Y in DPUTS in zsh.h line > 1314. Damn. Sorry, then. It was late. > > On a related note, should the following not restore IFS? > > > > sun4% IFS=@ set a@b@c@d; echo $IFS > > @ > > Here is what POSIX says: > > (2) Variable assignments specified with special built-in utilities > shall remain in effect after the built-in completes; this shall > not be the case with a regular built-in or other utility. > [ and ten other reasons why it wouldn't work...] Aha. There isn't a copy of the POSIX standard on the net, is there? Then I could stop identifying spurious non-bugs. But IFS=$OLDIFS is so *ugly*. > I'm writing these because these differences between zsh and POSIX are > probably the most important ones. Other than that zsh is now mostly POSIX > conformant (POSIX does not allow the MAGICEQUALS behaviour of the typeset > family but all other shells (bash, ksh93 and pdksh) do that unles > POSIXLY_CORRECT is defined). Those are pretty useful to know. Thanks. A ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-12 15:27 ` Zoltan Hidvegi 1996-07-12 16:01 ` Anthony Heading @ 1996-07-12 17:18 ` Bart Schaefer 1996-07-12 17:43 ` Zoltan Hidvegi 1 sibling, 1 reply; 12+ messages in thread From: Bart Schaefer @ 1996-07-12 17:18 UTC (permalink / raw) To: Zoltan Hidvegi, zsh-workers; +Cc: pws On Jul 12, 5:27pm, Zoltan Hidvegi wrote: } Subject: Re: Bug Report: Env Vars and shell functions } } > On a related note, should the following not restore IFS? } > } > sun4% IFS=@ set a@b@c@d; echo $IFS } > @ } } Here is what POSIX says: } } (2) Variable assignments specified with special built-in utilities } shall remain in effect after the built-in completes; this shall } not be the case with a regular built-in or other utility. } } And it also says that shell functions should be handled similarily to } special builtins (which means that recent patches from Peter and me make } zsh less conformant). But more intuitive. I suspect POSIX was merely codifying existing sh/ksh behavior there. } Zsh currently treats a builtin this way Clarity: Zsh treats a builtin the way it treats a shell function ... } only if the BINF_MAGICEQUALS flag } is set for the builtin. These builtins are: alias, declare, hash, integer, } local, readonly and typeset. [...] } Of course zsh does not conforms to the POSIX rule and handling of special } parameters in undoubtadly not the best but it also means that applications } should not expect local variable assignments before special builtins since } it may change in the future. Hopefully it would merely become dependent on a POSIX-compliance option; the whole reason for introducing the BINF_MAGICEQUALS behavior was so that applications could expect these local variable assignments. } Also note that command arguments are evaluated before variable assignments } so the above example will never work. Has this always been the case? (Peter?) Is this correct according to POSIX? Of what use is the BINF_MAGICEQUALS behavior if the args are evaluated before the variable gets assigned? } In a POSIX shell the command builtin can be used to execute special } builtins (in zsh it executes external command only). Note that command in } not listed among the special builtins above which means that the special } assignment behaviour can be prevented by prefixing a special builtin with } the command builtin (I'm talking about POSIX and not about zsh). Hmm. So `command typeset foo=bar ; echo $foo' has what effect in POSIX? } I'm writing these because these differences between zsh and POSIX are } probably the most important ones. Perhaps that means they should be recorded somewhere, maybe Etc/BUGS or a new file? (Where's the wish-list/ToDo-list nowadays?) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug Report: Env Vars and shell functions 1996-07-12 17:18 ` Bart Schaefer @ 1996-07-12 17:43 ` Zoltan Hidvegi 0 siblings, 0 replies; 12+ messages in thread From: Zoltan Hidvegi @ 1996-07-12 17:43 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers, pws > } And it also says that shell functions should be handled similarily to > } special builtins (which means that recent patches from Peter and me make > } zsh less conformant). > > But more intuitive. I suspect POSIX was merely codifying existing sh/ksh > behavior there. I agree. > } Zsh currently treats a builtin this way > > Clarity: Zsh treats a builtin the way it treats a shell function ... Not, the question is wether FOO=bar builtin should affect the shell environment or not. > } only if the BINF_MAGICEQUALS flag > } is set for the builtin. These builtins are: alias, declare, hash, integer, > } local, readonly and typeset. [...] > } Also note that command arguments are evaluated before variable assignments > } so the above example will never work. > > Has this always been the case? (Peter?) Is this correct according to > POSIX? Of what use is the BINF_MAGICEQUALS behavior if the args are > evaluated before the variable gets assigned? I think it has. Substitution is always done in the current shell environment while FOO=bar something type assignments are done after fork() (that's why they are local). Of course fork() is not called for builtins and functions but the behaviour should be similar (in the future some new builtins may be added as a builtin replacement for external commands and that change sould be transparent). > Hmm. So `command typeset foo=bar ; echo $foo' has what effect in POSIX? The command prefix makes special builtins behave like external commands. So command typeset foo=bar is probably a no-op in POSIX. It is a no-op in pdksh but not in bash and ksh93. But what I really meant is that in POSIX (and in zsh too) FOO=bar export FOO exports foo but FOO=bar command export FOO is just a no-op. Bash does not know that but ksh93 and pdksh do. > } I'm writing these because these differences between zsh and POSIX are > } probably the most important ones. > > Perhaps that means they should be recorded somewhere, maybe Etc/BUGS or > a new file? (Where's the wish-list/ToDo-list nowadays?) I'd like to add a COMPATIBILITY section to the manual where these things will be documented. Unfortunately at the moment I'm quite busyly fixing the zsh code which I consider more important. Zoltan ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1996-07-12 17:51 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-07-08 3:49 Bug Report: Env Vars and shell functions Peter Bray 1996-07-08 8:58 ` Bart Schaefer 1996-07-08 12:49 ` Peter Stephenson 1996-07-10 2:33 ` Zoltan Hidvegi 1996-07-10 12:19 ` Vinnie Shelton 1996-07-10 13:45 ` Zoltan Hidvegi 1996-07-11 22:11 ` Anthony Heading 1996-07-12 12:17 ` Peter Stephenson 1996-07-12 15:27 ` Zoltan Hidvegi 1996-07-12 16:01 ` Anthony Heading 1996-07-12 17:18 ` Bart Schaefer 1996-07-12 17:43 ` Zoltan Hidvegi
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).