From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7312 invoked from network); 21 Apr 2004 08:37:09 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 21 Apr 2004 08:37:09 -0000 Received: (qmail 16361 invoked by alias); 21 Apr 2004 08:36:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19807 Received: (qmail 22495 invoked from network); 21 Apr 2004 08:21:51 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 21 Apr 2004 08:21:51 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [130.225.247.86] by sunsite.dk (MessageWall 1.0.8) with SMTP; 21 Apr 2004 8:21:50 -0000 Received: (qmail 13254 invoked from network); 21 Apr 2004 08:21:50 -0000 Received: from lakermmtao03.cox.net (68.230.240.36) by a.mx.sunsite.dk with SMTP; 21 Apr 2004 08:21:48 -0000 Received: from quark.hightek.org ([68.12.75.33]) by lakermmtao03.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040421082120.KBHH2958.lakermmtao03.cox.net@quark.hightek.org> for ; Wed, 21 Apr 2004 04:21:20 -0400 Received: by quark.hightek.org (Postfix, from userid 501) id 7972512408; Wed, 21 Apr 2004 03:21:51 -0500 (CDT) Date: Wed, 21 Apr 2004 03:21:51 -0500 From: Vincent Stemen To: zsh-workers@sunsite.dk Subject: Re: FreeBSD compatability feature request Message-ID: <20040421082151.GA61057@quark.hightek.org> References: <20040417222222.GA27230@quark.hightek.org> <21533.1082374109@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21533.1082374109@csr.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: * X-Spam-Status: No, hits=1.5 required=6.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Hits: 1.5 On Mon, Apr 19, 2004 at 12:28:29PM +0100, Peter Stephenson wrote: > Vincent Stemen wrote: > > Here is the FreeBSD manual entry: > > > > -T trapsasync > > When waiting for a child, execute traps immediately. If this > > option is not set, traps are executed after the child exits, > > as specified in IEEE Std 1003.2 (``POSIX.2'') This nonstandard > > option is useful for putting guarding shells around children > > that block signals. The surrounding shell may kill the child > > or it may just return control to the tty and leave the child > > alone, like this: > > > > sh -T -c "trap 'exit 1' 2 ; some-blocking-program" > > Good(ish) news... > > Just tried this out, and it looks like the `trapsasync' behaviour > is the standard (and only) one in zsh. Hence it doesn't conform to > POSIX (which isn't likely to be an earth-shattering revelation to zsh > regulars). > > This means that almost everything we need for both behaviours is already > there. It remains to add the option TRAPS_ASYNC, turned on by default > in non-Bourne mode for compatibility, and make sure we can still handle > SIGCHLD when the option is unset. > > Someone already had the foresight to handle sh options separately, so -T > does the right thing in sh or ksh emulation and the example you gave > should now work as expected. > > Further follow-ups should probably go to zsh-workers. > Ok, I applied the patch to zsh-4.2.0 and tested under FreeBSD-5.2.1-RELEASE. It seems to work just fine. I did not test the actual signal handling but FreeBSD was able to boot without getting errors from the init scripts that use "set -T". I was also pleased to find that the other problem is fixed in 4.2.0 where eval was returning the result of the last run command if eval was given a null argument. Previously, that had caused eval to return false in one of the scripts causing the rootfs to stay mounted read only, which of course caused many other errors. After replacing /bin/sh with zsh, it was able to fully boot up and initialize the system except for one other problem, which appears to be a different bug in sh emulation mode. It hangs when running the nfsd init script. If I c out of it, the rest of the system comes up, but without NFS. I finally isolated the problem. Below is a small script, called t, that reproduces it. # cat t _find_processes() { ps | while read pid command do echo "pid=$pid $command" done >&2 echo "xxx Exited loop xxxxxxxxxxxxxxxxxxxxxxx" >&2 } xxx=$(_find_processes) #--- end of script ------- If I run it by calling zsh as sh, it hangs on the read command after the last line of output from ps and I have to break out of it. root@quark # ./sh t pid=PID TT STAT TIME COMMAND pid=24781 p0 I 0:00.02 su pid=24782 p0 I 0:00.23 su (zsh) .. .. pid=578 v6 IWs+ 0:00.00 /usr/libexec/getty Pc ttyv6 pid=579 v7 IWs+ 0:00.00 /usr/libexec/getty Pc ttyv7 ^C root@quark # If I run it as zsh, it works properly. root@quark # ./zsh t pid=PID TT STAT TIME COMMAND pid=24781 p0 I 0:00.02 su pid=24782 p0 I 0:00.23 su (zsh) .. .. pid=578 v6 IWs+ 0:00.00 /usr/libexec/getty Pc ttyv6 pid=579 v7 IWs+ 0:00.00 /usr/libexec/getty Pc ttyv7 xxx Exited loop xxxxxxxxxxxxxxxxxxxxxxx root@quark # It only hangs when the function is called from inside of $() or back ticks. Calling it outside of that worked correctly. Regards, Vincent -- Vincent Stemen Avoid the VeriSign/Network Solutions domain registration trap! http://www.InetAddresses.net