Date: 21 Aug 2002 09:48:34 -0400 From: Lowell Gilbert <freebsd-stable-local@be-well.no-ip.com> To: stable@freebsd.org Subject: Re: minor annoyances Message-ID: <44k7mktj9p.fsf@be-well.ilk.org> In-Reply-To: <E17hSKW-00008v-00@mailhost.firstcallgroup.co.uk> References: <E17hSKW-00008v-00@mailhost.firstcallgroup.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Pete French <pfrench@firstcallgroup.co.uk> writes: > > If it works, '(aaa &) && bb' can't mean anything other than 'aaa & bb'. > > The "bb" always executes, regardless of the result of "aaa". > > It does ? I would have thought that this would only execute "bb" if the > fork succeeds on the right hand side. That would be a useful feature, but it's never been an intentional one, so it's hard to fault the changes that "broke" it. The standard specifically allows (but does not require) the parent shell to exit if the fork fails, so there's definitely not agreement on the expected behaviour. [This has long been the behaviour that sh follows, by the way.] Some shells explicitly set the return code to 0 after an '&' operator. > How else do you test for fork failing ? Hmm. That never worked anyway, but it's a good idea. I don't know that anyone intended to provide a way to do that. If you were going to make a mechanism from scratch, I'd be inclined toward raising a signal, but this really isn't my area of standards expertise. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44k7mktj9p.fsf>