Bug Report: Env Vars and shell functions

Bug Report: Env Vars and shell functions

[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

Re: Bug Report: Env Vars and shell functions

[Bart Schaefer]

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"

Re: Bug Report: Env Vars and shell functions

[Peter Stephenson]

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.

Re: Bug Report: Env Vars and shell functions

[Zoltan Hidvegi]

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);
      }
  }

Re: Bug Report: Env Vars and shell functions

[Vinnie Shelton]

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

Re: Bug Report: Env Vars and shell functions

[Zoltan Hidvegi]

> 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 ----

Re: Bug Report: Env Vars and shell functions

[Anthony Heading]

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

===================================================

Re: Bug Report: Env Vars and shell functions

[Peter Stephenson]

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.

Re: Bug Report: Env Vars and shell functions

[Zoltan Hidvegi]

> 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

Re: Bug Report: Env Vars and shell functions

[Anthony Heading]

> 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

Re: Bug Report: Env Vars and shell functions

[Bart Schaefer]

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"

Re: Bug Report: Env Vars and shell functions

[Zoltan Hidvegi]

> } 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