From: Vincent Stemen <zsh@hightek.org>
To: zsh-workers@sunsite.dk
Subject: Re: FreeBSD compatability feature request
Date: Wed, 21 Apr 2004 03:21:51 -0500 [thread overview]
Message-ID: <20040421082151.GA61057@quark.hightek.org> (raw)
In-Reply-To: <21533.1082374109@csr.com>
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
next parent reply other threads:[~2004-04-21 8:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040417222222.GA27230@quark.hightek.org>
[not found] ` <21533.1082374109@csr.com>
2004-04-21 8:21 ` Vincent Stemen [this message]
2004-04-21 10:00 ` Peter Stephenson
2004-04-21 11:05 ` PATCH: (2) " Peter Stephenson
2004-04-22 8:59 ` Vincent Stemen
2004-04-22 9:59 ` Peter Stephenson
2004-04-22 10:17 ` Peter Stephenson
2004-04-22 16:09 ` Jos Backus
2004-04-23 5:30 ` Vincent Stemen
2004-04-23 9:56 ` Peter Stephenson
2004-04-27 3:56 ` Bart Schaefer
2004-04-27 9:58 ` Peter Stephenson
2004-04-29 2:16 ` Vincent Stemen
2004-04-30 21:26 ` PATCH: (3) " Peter Stephenson
2004-05-01 1:45 ` Vincent Stemen
2004-05-01 2:23 ` Vincent Stemen
2004-05-04 7:17 ` PATCH: (3) - FreeBSD compatability issue resolved Vincent Stemen
2004-05-04 9:28 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040421082151.GA61057@quark.hightek.org \
--to=zsh@hightek.org \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).