From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id BAA18959 for ; Sat, 13 Jul 1996 01:40:26 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id LAA13352; Fri, 12 Jul 1996 11:28:32 -0400 (EDT) Resent-Date: Fri, 12 Jul 1996 11:28:32 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199607121527.RAA09051@bolyai.cs.elte.hu> Subject: Re: Bug Report: Env Vars and shell functions To: aheading@jpmorgan.com (Anthony Heading) Date: Fri, 12 Jul 1996 17:27:28 +0200 (MET DST) Cc: acs@world.std.com, pws@ifh.de, zsh-workers@math.gatech.edu In-Reply-To: <199607112211.XAA18522@et-sun4.uk.jpmorgan.com> from Anthony Heading at "Jul 11, 96 11:11:24 pm" Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368 X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"XHwBA3.0.VG3.Vycvn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1624 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > 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