Re: FreeBSD compatability feature request

[Vincent Stemen <zsh@xxxxxxxxxxx>]

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